Unlocking the full potential of Domain-Driven Design
With Full Stack Europe, Antwerp has a new diamond in its midst. 23 October 2019 marked the start of a new conference on all things full stack and beyond. Props to Freek Van der Herten and Dries Vints for organizing the conference. It never felt like a first edition.
Full Stack? It means that developers, like myself, work on all the parts of a site, regardless of whether it’s technically front-end or back-end.
During the 3-day conference, I joined diverse talks ranging from hard technical stuff to more philosophical reflections on software development.
I was particularly impressed by Mathias Verraes. He gave a hands-on, in-depth workshop about Domain-Driven Design (DDD). Mathias focused on the underlying principles and heuristics for building great domain-centric object-oriented code.
Let me walk you through some of the most interesting principles of DDD.
DDD Principle 1: Challenge your client
A big part of Domain-Driven Design is interaction with the client. In order to understand the domain, you need to challenge the client at every point.
Every decision and every change should be met with the simple question of ‘why’. This builds an understanding of the business processes but also helps the client discover what they really want instead of what they think they want.
DDD Principle 2: Use the language of your client
You should follow the language of the client as closely as possible in the code. In fact, in an ideal world, the client or business analyst should be able to understand the domain code with little to no help from the developers.
Why?
Well, natural language is hard and ambiguous. A result of modeling the business processes is that you create a formal language that starts to describe what you are modeling.
The client or business analyst should be able to understand the domain code with little to no help from the developers.
Businesses will start to talk about their processes in the same terms like the ones you used. Your code becomes documentation and the business gains a better understanding of themselves. DDD works in both directions.
DDD Principle 3: Iterative development
Because your model needs to closely reflect the business it’s modeling, every change in the domain should be reflected by a change in the model.
Iterative development is a must, as opposed to the incremental development that happens in many ‘agile’ teams.
DDD Principle 4: Focused design
Another interesting side of DDD is the opposition to generic implementations. Generic implementations have increased complexity and their generic nature makes it difficult to closely describe a domain-specific problem.
The sales department, for example, has different interests than the supply chain team. Your code should reflect this by keeping these domains separate.
In conclusion: Verraes encourages all full stack developers to have a deep understanding of the domain and to reflect it in the code.
About the author
Ruven Salamon (27) is a Full Stack Developer with a passion for electronic music, hi-bit games, and software architecture and design.
Right now Rombit is looking for Full Stack Developers! Check out the vacancy.