DDD The Lost Discipline
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:
* Organization
* 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 Benefits
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.
DDD Challenges
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 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.
Cheers,
Diego Pacheco
