Let’s model the business domain

elevysi · 23 April 2019 |

A domain is a field of study that defines a set of common requirements, terminology, and functionality for any software program constructed to solve a problem in the area of computer programming, known as domain engineering. The word domain is also taken as a synonym of application domain.

https://en.wikipedia.org/wiki/Domain_(software_engineering)

I will be using the term domain for the business domain (i.e. the set of requirements from the business as a whole) while I will be referring to each application as a service. Each service shall have its own domain but I will restrain myself from mixing the terminology for one case to the other.

Envisioning the scope of your application is key to controlled expansion, re-factoring, and maintenance. The choices at design phase will determine how easy or difficult it can be to go in a different direction or to improve on the functionalities already offered by an application. Fortunately, the buzz around the tech world often follows the challenges faced in the state of the art organizations. Lately, the word has been Microservices and the word has been spread pretty much, and rightfully so! The idea of dividing your business domain into several smaller independent services can help control and handle the growth, the evolution of technology and the maintenance of your domain. This will usually involve higher efforts at initial phase but once the underlying aspects have been set-up, evolution will tremendously benefit from this initial planning and set-up.

Enough with the motivation, let’s talk about a real-life case scenario - my case - and my business domain.
What I want to achieve is a space for personal expression; I would like to create an outlet to reflect the creativity I wish to put out there and share with the world. I want to share notes which in most cases would be writings, music, pictures and videos. These notes can be categorized so as to organize the data or secure their access to the targeted audience. I will refer to this aspect as the Blogging / Blog service.

I also want to bring some life around the notes by letting people react to them by building a community that would be interacting through messaging and internal communications. These people need to be identifiable so as we know whom the interactions involve. I refer to these entities as profiles; these are entities used to group the activities related to the same logical person. I keep presenting this as a personal outlet, nevertheless why would I be the only one able to express and create notes? Even if I am the sole creator for the moment, that does not mean that the same logic cannot be used by another person, through the same platform.

Moreover, the same person can possess different profiles on the platform so as to showcase the different aspects of their activities. A person can have a basic profile (which they use to comment on notes for instance as themselves) and a more elaborated profile, for different activities such as a business, an association or a volunteering activity for instance. Although this is the same person, different profiles can be used by the same person, depending on the activity one wishes to accomplish on the platform. I will refer to the aspect of grouping the activities within a profile as well as being able to exchange and communicate as the Social / Community service.

Whether be it through the aspect of creating and sharing notes or interacting and communicating, one aspect is shared between the blogging and the social services. There needs to be some identification of the people involved and an authorization logic so as to know who is allowed to do what. I will refer to this aspect as the Authentication service, one that will handle the platform users.

Eventually, I want to evolve the platform towards a showcase of articles that can be purchased by the members, through the website itself or through the redirection to a merchant site. The idea is that one should be able to describe their articles and key points about the sale of these. I will refer to this as the Shopping / Shop service. And who doesn’t like a good photo sharing app, right? I like the range of pictures these provide to express one’s artistic side. I will refer to this part as the Photo Sharing service. 

“They do not need to be the same application”

Although serving the same domain, the Blogging, Social, Shopping, Photo Sharing and Authentication services do not need to be the same application. They can exist independently and communicate through the exchange of entities to which they would be developed to react to (in case they need to). They appear as the same overall unit to the end-user (through a similar user interface identity), however this is just a facade. Keeping their independence is a key factor to the success of the growth and maintenance of the business domain. We need to ensure that each one handles its business and does not cross the boundaries of what it is aimed to achieve. If an exchange is needed, the server needs to make the data available, through REST or subscription / broadcast mechanism for instance, and does not need to know about the client.

Each service should be able to exist, up to a certain extent, without the co-existence of the other services, addressing its share of the business domain. Simply put, one should be able to remove the service from the domain and put it into a different domain and it would still be operational on its own. This aspect emphasizes the importance of portability in such a landscape to benefit from all the advantages offered by the services independence. Within a container, one can basically move all the parts of the ecosystem around by gradually bringing them down, replacing them or making them obsolete with little care to how the other components of the business domain are affected.

Obviously, there is gonna be a degradation of service from the overall business domain but this should not lead us to an out of business state. For instance, we would need authenticated users to be able to create notes hence the aspect of creating notes on the Blogging service can be handicapped from the lack of an Authentication service.
However, if the notes are readable to everyone, the downfall of the Authentication service does not stop us from showing the notes to an audience. You can live with showing notes/ comments but not showing the authors of these notes/ comments. Moreover, there needs to be an implementation within the services of how these aspects can be handled when a service of the business domain is down. For instance, one can fetch from an alternative database, call a fallback method when failure has been detected from one service. The overall landscape needs to be designed to be able to detect and address such failures.

Each individual service should be able to work with different implementations of the other services from the business domain, provided the API remains the same and the communication between the services in unaltered (and vice-versa) -  the guys responsible for Android at Google know a thing or two about this, ain’t it right Oracle? ;-)

Onto the technical part now; the business domain consist of five main services, each one to be deployed in its own container (Docker containers):

  • A Blogging Service
  • A Social Service
  • An Authentication Service
  • A Shopping Service
  • A Photo Sharing Service

Each of these services have a corresponding database, implemented as a Mysql database, running each on its own server. Besides the basic services, some more services are implemented to support application level requirements such as API communications:

  • A Configuration Service to hold the configuration files of the various services involved in the domain so that the change of a property does not involve the redeployment of the entire service
  • A Proxy Service to be able to physically identify and direct requests to the right service. Each service from the business domain needs to register itself against the proxy service
  • A Service Gateway Service to implement special routing given the needs of the business
  • A continuous delivery application (Jenkins) for deploying the various services

Most of these services have been implemented as Spring Boot applications except for the Photo Sharing Service, implemented using the MEAN (MongoDB - Express - Angular- NodeJS) stack.

Some key questions need to be considered when scoping the services. How much services are you deriving from the business domain? You can pretty much isolate each aspect of the business and implement it as a standalone service. You might run the risk of having a multitude of services which handle very small aspects of the business domain hence introducing more complexity by imploding the number of individual services to handle and maintain. Your infrastructure needs to be adapted to the services you have in place, considering that the more individual services you have, the more resources you need from the infrastructure side.