Domain-driven design facilitates the use of microservices for applications.
The benefits of deploying microservices for applications are numerous. But how to design microservices that are best suited for your applications? Domain-driven design is most helpful in this regard.
Domain-driven design is a practical approach towards object-oriented software development. Here is how it’s done.
Unlock the future of intelligent applications with our cutting-edge Generative AI integration services!
Start with Entities
Entities provide the starting point for microservices development. An entity is an object characterized by its identity. Entities possess unique identifiers. Entities also possess attributes that could change; however, the identifier remains the same for a person.
A person is an example of an example for an entity. In the US, a person has a unique identifier like the Social Security Number. The person will also have a certain name, surname, phone number, and address. These attributes may change; however, the person will remain the same.
A well-defined lifecycle should characterize entity objects. There should also be a clear definition of the identity relationship.
An entity may be clearly defined and may have an identifier, but it may not exist independently. An aggregate is hence, a combination of entities.
A retail store can give you a good example of an entity-aggregate relationship. Walking down the soda aisle inside the grocery, you can purchase a 12 pack soda carton. There is a bar code on each can inside the carton for unique identification. However, the single can may not be sold separately from the rest of the carton. All these cans may be described as dependent entities. Whereas the carton is the root entity. The carton here is the aggregate root; since then, it is the root that describes the lifecycle of the dependent entity.
Value Objects
Value objects are defined differently. They do not have any conceptual identity. You cannot distinguish between a value object from another of the same kind. If all objects in the system are entities, managing and assessing each object’s identity can be onerous and will adversely impact performance.
Here is an illustration of the value object concept. When visiting the bank, you will almost certainly want access to your account. The bank account here is an entity. Then the current account balance is an example of a value object. The current account balance can vary over time. Likewise, the object value can change.
Repository
The repository is another central tenet in domain-driven design. Here is an issue to be dealt with. Aggregates, as well as non-aggregate entities, may be found using an attribute-based search. While providing the search mechanism, you want technical database infrastructure details to remain hidden. The repository helps you with this. It also helps to hide the complexity of the database design.
Services
In many domains, certain operations are not conceptually part of any given object. In prior design approaches, this operation was made a part of the entity-based model. However, there were negative consequences.
The best way of modeling these objects is to treat them as standalone interfaces known as services. Here are the rules for services.
- They are stateless
- The interface definition includes various other elements within the domain model – value objects and entities.
- They are related to the domain concept that is not linked with any specific value object or entity.
Such operations belong to the business domain. They are not technicalities of the implementation. Hence, ‘logging’, ‘authentication’, and ‘login’ are not examples of services defined thus. ‘Funds transfer’ in banking, on the other hand, is an example of such services.
SERVICE DISABLED VETERAN OWNED SMALL BUSINESS (SDVOSB)
Their Use in Domain-Driven Design
The domain-driven-design workflow will use object types like services, value objects, repositories, and entities described above.
Such object types are essential for microservices design. All objects thus described may not be included in your microservices design. Some might be present in the service implementation.
API and Objects
Which one has greater priority? Designing the API or designing objects that implement the API? Many gave priority to object design. But this method created issues in API granularity. APIs then resembled technical interfaces rather than business interfaces.
But when you begin with API design, you can address the business problem without getting lost in the technical intricacies of the specific implementation. Pact testing is a somewhat different kind of API-first. A pact is a tool for contract unit-testing for ensuring that services are capable of communicating with one another.
When writing the pact test, the unit-test for the provider and consumer is carried out separately. An API request is given to a mock provider for testing an API consumer, and a response is received. For testing the provider, the mock consumer sends a request while the provider gives the actual response. Verification is necessary for confirming that services operate as intended. Testing is carried out just for certain functions that the consumer will be using.
There is another consideration for API design. Pay attention to whether the API indicates functions or entities. Resource API pattern is the beginning step for mapping. This is a basic definition of the REST idea. A URI is assigned for all instances and procedures of domain data. You then utilize the HTTP application protocol for defining how standard services work.
Define Boundaries
Microservices design can utilize another domain-driven-design concept. The bounded context provides an explicit definition of your model boundaries. This idea is essential for big software projects. The bounded concept limits what a particular team will be working on. It also enables them to use their own definitions that fit the context.
When defining the bounded context, you have to mention who will be using it, how they will do it, and how it applies to a bigger application context.
Small Disadvantaged Business
Small Disadvantaged Business (SDB) provides access to specialized skills and capabilities contributing to improved competitiveness and efficiency.
Conclusion for Best Practices in Domain Driven Design for Microservices
In short, following the best practices in domain driven design for microservices will to help you organize APIs in a logical configuration.
Further blogs within this Best Practices in Domain Driven Design for Microservices category.