The OOP concepts can be applied to the design of microservices, not only in the internal design of the application but also in the architecture and the business division. When it comes to Domain-Driven Design (DDD), it is no different.

DDD came from the book Domain-Driven Design written by Eric Evans. The Evans book is a large catalog of patterns, coming from over 20 years of the author's experience developing software using OOP. It is very important to note that OOP is not only inheritance, interfaces, or anything else of the type. OOP's main ideas are as follows:

Evans's book is divided into four parts:

All the preceding parts can be applied to microservices. Model building blocks-driven design and refactoring to deeply understand the model internally applies to microservices, that is, the code itself. The others can be applied either internally in the software, but can also be used to design microservices and their signatures.

The first part is emphatic about the need to use ubiquitous language for communication between those responsible for the business, and the engineering team responsible for the development. This language consists of terms that are part of everyday conversations between business experts and development teams. Everyone should use the same terms in spoken language, the source code, and the signing of microservices. This means that when the business specialist says, The home page should seek breaking news with the title and description the ubiquitous language applied in the code will be represented as follows:

This type of communication will mitigate errors in understanding requirements and maintain the general knowledge about application unison. Another important point is that, with the ubiquitous language, identifying areas is simpler because, as interactions have standardized terms, a word may indicate something new.

The fourth part will clarify the boundaries of a microservice and ease of management between the parties. Besides having a ubiquitous language used in the development of a consistent and adequate microservice, some strategies are necessary for dealing with complex systems, where multiple pieces of software (developed by several teams) interact. Delimit the context in which each team works and what is the degree of interaction between these teams and these contexts? Of the many tools that the DDD provides us, three are more prominent for efficient microservices:

Thinking about the application we are working on, the DDD would be very useful for avoiding misunderstandings in the interpretation of how microservices should work. A common misconception in news systems is about the terms user and author; both are users of the system, one as a player and another as publisher, but if a product owner says, "The user published bad news" we have a problem in communication between product teams and development teams. This may result in an inconsistent microservice within the business itself. Another problem is that the phrase spoken earlier by the product owner suggests an unwanted feature, which is a user who can publish materials. DDD is just thinking about defining the microservice domain and standardizing terms to generate consistent internal models and an API with solid meaning. The difference in meanings or representations for the same attribute is known as a semantic gap, and is exactly what we are dealing with throughout the chapter.

Besides the aspects mentioned previously, helping to create microservices intact, there is a feature of DDD which undoubtedly is the most important when it comes to designing microservices. The concept of bounded contexts is essential to determine the range of a microservice and in the end, the responsibility that the microservice has. The most important thing is understanding that without these, coupling limits will be high and concepts such as single responsibility can never be achieved.

Another principle that is applied to microservices and comes from the OOP world is specifically the letter S in SOLID. What could be thought before the class level should now be through the application level, so that microservices can be really micro in terms of what really matters at the domain level.

The microservice domain cannot be large; on the contrary, it must be limited. The limits that were cited in DDD return to be applied now and with more intensity. Precisely, the limits in the microservice domain is what will make this application sensitive to changes and open to the perception of possible errors.

It is a very common difficulty in maintaining pure microservices in their domains. The natural tendency, either by habit or ignorance, is to try to group all the business rules or similar codes in the same microservice, without even understanding whether they are part of the same domain.

To illustrate, think of the application on which we are working, our news portal. News and recommendations virtually work together all the time. Recommendations always put together some news that has some of the related labels. At first, it makes sense, because as the recommendations are always related to the news, apparently this does not cause a problem and, moreover, could reduce problems such as network latency. The main concept could be represented by the following diagram:

However, creating a microservice containing news and recommendations will generate unnecessary and very expensive engagement for future changes. In a simple demonstration exercise, we can think of a number of business changes with which this engagement would generate problems.

A new business requirement arose. Those responsible for thinking about the product had an idea to use recommendations to compose a personal home page according to the news that stands out most in our portal. So, the recommendations aren't just connected to the news anymore, but to the user too. With this new requirement, some problems relating to the coupling done previously will emerge at the level of deployment, scalability, and maintenance features code.

Based on the new requirement mentioned previously, it is clear that news and recommendations work together, but they are totally different domains from each other. Identifying areas to apply the principle of sole responsibility for each microservice is crucial to application architecture. The following diagram shows the main idea of the microservice distribution:

Working together and in concert, Home requests information either from News or Recommendation. There are some forms of data orchestration that we will come to later in the book, but now it is important to understand that Home can consult separate services and compose the received data conveniently.

The separation of News and Recommendation results in an application where the deploy becomes a simpler, more consistent code base and the fully defined and specific business domain for a purpose.

The published interface is a term that usually generates a lot of confusion with the public interface. It is critical to understand the difference between the two terms: microservices and distributed source systems.

Think of a microservice. All internal microservice code will be used and shared among the development team; class methods are abstractions or attributes and can all be part of the public interface between teams. This is because of the convenience to notify and make changes in the event of possible refactoring. There is no point in generating a lot of bureaucracy at the development level, just for the features to gain speed in the implementation.

When it comes to the published interface, however, it is different. The published interface is what the microservice developers release. The published interface is what will be consumed by the internet. A good example is the Single Sign-On (SSO) API. Imagine that APIs suffer sudden changes to implement new features such as security and that these changes do not have a good system of alerts for all customers of these APIs. It is simply not appropriate to use this SSO service, because of updates, the API client suffers from incompatibilities.

Published interfaces should have more control and be more resilient to refactoring. Usually, they apply only to external application clients. The less possible changes in the level of the signatures, the better. The following diagram shows the possibility of maintaining the published interface signature:

Some concepts are important for published interfaces, such as:

It is common to think of the concept of public interface versus published interface as something similar to the public versus private OOP, but they are actually different. The published interface does not mean depriving the client of resources, but rather directing the customer to consume adequate resources resiliently.