DDD is a modeling method highly focused on business domains and comunication. DDD solves several issues we have with Services/Microservices and Backend Systems in General. One of the biggest challenges in Services but especially microservices is to find the right boundaries meaning what should belong to one service or what should belong to another service. It’s common for engineers, often, just write code right and ignore the design. Modeling is hard for several reasons but one reason is the software might work, even with the wrong design. The right Design starts placing the code in the right place. DDD is key to that. DDD is not only about placing the code in the right place but also about how we communicate with the business to figure out that and other ways(DDD Patterns) to express the solutions.
DDD is a nutshell
DDD(Domain Driven Design) is about comunication. Comunication between the business and the business experts(not business proxies) and the engineers(the folks who build the solution). DDD’s main interest is in the CORE Domain of the problem you want to solve. In order to explore the comunication between business experts and engineers, we should focus on a common language which for DDD is called “Ubiquitous language”. DDD Has many concepts and patterns such as:
* Domain: Logical area that defines your problem. i.e: Retail, HR, purchase, etc.
* Bounded Context: Logical Boundary on the code for the solution domain, can be defined as:
* Code Base
* Database Schemas
* Services and Microservices
* Layered Architecture: Separated Core Domain from UI, Persistence, DBs.
* Entities: Domain Objects defined by unique id (UUID). i.e: User, Customer, Job, Message.
* Value Objects: Unchangeable Objects, has attributes but not unique ID. i.e: Name, JobTitle, Address.
* Aggregates: Cluster Value Objects into aggregates to define a boundary. One entity should be the root of the aggregate. So external objects hold a reference on the root only.
* Factories: Use to create complex objects and aggregates. The client does not need to know the internal details.
* Domain Events: Record Discrete event to model activity within a system.
* Services: Significant process or transformation into the domain. When is not the natural responsibility of the Entity or VO(Value Objects) objects.
* Repository: It’s a service, uses a global interface to provide access to all entities and value objects within a particular aggregate collection.
* Context Map: Diagram to enforce strategy domain integrity.
* Bounded Context Patterns:
* Anti-Corruption Layer: Wrapper for Legacy API or protect the domain from bad API.
* Shared-Kernel: N-Bounded contexts depending on shared kernel(core).
* Customer/Supplier: Like a client/server has a high dependency.
* Conformist: UpStream and Downstream teams that ARE NOT ALIGNED (accept as it is).
* Partner: Mutual Dependency on both contexts and high alignment is needed for proper modeling.
In order to set the record straight, you dont need to use all patterns to be doing DDD. By the way, if you are using Spring Data and have Repositories that alone does not mean you are doing DDD. DDD is a process, it’s not a one-time discrete shot. There is an agile collaborative modeling exercise called Event Storming which can help you a lot. Event Storming can be quite useful to figure out inconsistencies in the breakdown of your services and save lots of refactoring and headaches in the future.
DDD has solid benefits, such as:
* Better comunication
* Help Organization to retain knowledge (often a huge issue at scale and as the time pass)
* More flexibility via strong design and encapsulation
DDD will not do any magic for you. It’s just a tool, at the end of the day it depends on how you use it.
Like anything in software, there are trade-offs. DDD might not work well at all in a very technical project. It’s also required to have a domain expert working with the engineering team, which unfortunately is complex nowadays.
Reality and DDD
In order to organizations scale, they often split Strategy and Execution, Product and Technology. Specific people are often used as proxies to answer questions in a sense of priorities and “representation of interests”. That representation happens via PM(product Managers), PM(Project Manager), PO(Product Owner), BA(Bussiness analysts). There are good PMs, POs, and BAs out there but wich scale you need more and more, and unfortunately lots of times you have weak and low-performance in those positions.
When a startup starts by definition and nature the company is super glued with the customers, the problem, and the real needs. As a company succeeds and starts growing end ends ups as an enterprise that connection starts to get weak. DDD might be an important tool to help to promote not only comunication but also sharing an understanding of real business problems.
The Way forward
Recently, Uber rediscovered DDD and applied for they hyper-scale microservices solution, called DOMA(Domain Oriented Microservices Architecture). DDD has a perfect FIT with SOA and Microservices. It’s a great modeling exercise and it’s being used for decades in our industry. Analysis and Design are lost disciplines like DDD I hope we can rediscover this techniques and leverage and involve them in the present and the future.
Originally published at http://diego-pacheco.blogspot.com on September 19, 2020.