Domain Driven Design, in short DDD, is an approach to develop software in which the domain (a sphere of knowledge, influence, or activity) is of great importance. By tightly relating the domain to the software, the software is given meaning. The relation resides in domain models: a model describing one specific domain in a ubiquitous language (a common language used by all team members both from a business and a technical perspective) in such a way it can be used to solve real problems. The models and their boundaries, called bounded contexts, are discovered and explored in creative collaboration, in which the focus lies on the strategically distinctive domains, the core domain. Supporting and generic domains indicate parts of the system that are necessary to support the core domain but are not of strategic importance. This way, DDD combines both tactical and strategic design.
A nice introduction to DDD is a booklet by Scott Millet and can be downloaded at leanpub or watch the videos.
We’d like to share and reflect on some key aspects and trends of DDD with our favourite quotes.
- “You need to understand your business model before creating bounded contexts”, NICK TUNE: Understanding your business model will provide the necessary insights of which (software) components are core to your organisation (most valuable). They will reflect your strategic goals and therefore are to be kept safe and sound apart from anything just being supportive to that. Important characteristics are complexity and customization. Be aware, not all that is complex and custom reflects your core.
- “When the purpose (problem space) is not clear, you get the wrong solutions”, LORRAINE STEYN: Before creating a solution you need to understand the purpose or problem you want to solve or you will get the wrong solution. Understanding is a balancing act on getting as much context as possible about the whole and get deep insight into small details to get the real beauty or issues on the table.
- “Domain language enabled the doctor* (domain expert) to spot issues in our rules, KONSTANTIN KUDRYASHOV: is decisive for meaning. A ‘condition’ has a different meaning in the context of a hospital and a law context. Business alignment is about engineers and domain experts speaking the same language which is reflected in the model/code. For this to happen, you need to talk! Explore, ask, ask even further, elaborate and in the end define (for now). Getting this right enables domain experts to validate your rules, your code and spotting necessary changes. No more (lost in) translations.
- “Good vs Bad architecture isn’t about what it is, but about what it is becoming”, KONSTANTIN KUDRYASHOV: If anything is certain, it is: the world, the context will change. Invest in designs that keep options open. Today is no guarantee for tomorrow, especially when you are going to change the world, the context, by adding something new to it: your solution.
- “Don’t constrain yourself by requirements and scope (MVP), when learning about the domain”, ANDREW HARMEL-LAW, GAYATHRI THIYAGARAJAN: There is no silver bullet. There are heuristics, frameworks, rules of thumb, patterns though to help you understanding, exploring, seeing solutions that solve the (right) problem. It’s about trade-offs doing justice to the problem at hand, the degrees of flexibility needed for certain aspects of the solution.
- “Making a change to the world, will change the world, so the next thing cannot be predicted. Insist on feedback”, KENT BECK: Make short feedback loops an intrinsic part of your solution. Does the outcome meet your expectations (or not), is the outcome desired, does it help solving your problem? What should be your next step?
- "Make (the) change easy, then make (the) easy change", KENT BECK: The cost of maintenance corresponds to the cost of change, which corresponds to the cost of big changes. A small change can become an expensive change when coupling is high.
- “Everything decoupled is not a system, it is a bunch of things”, VLADIK KHONONOV: coupled system comes with a cost. A decoupled system comes with a cost as well. Coupling/cohesion is a design decision and defines the relationship between components.
- “As the domain evolves, the sociotechnical architecture should evolve to maximise flow in core domains”, NICK TUNE: Ideally, domains are aligned with bounded contexts and these are in turn aligned with teams. One team can design, build and run multiple bounded contexts, the other way around means trouble.How teams and bounded contexts interact follows the system design. Optimizing the system (design) and interaction modes optimizes value.
At Blueriq, we apply DDD practices to discover and create business, domain and knowledge driven solutions, as we’ve been doing for the past decades. We call it Business Engineering. Our Blueriq platform enables us to minimize translations between the problem domain and the solution. The key is our Blueriq domain model directly describing knowledge, rules, characteristics in natural (ubiquitous) language. Together with our customers we discover their domains, develop a ubiquitous language, all team members speak, and create their business domain model they can validate accordingly.
