-t Tags:: 📚Books, Software Architecture
- Author:: Eric Evans
- Liked:: 8
- Link:: Domain-Driven Design: Tackling Complexity in the Heart of Software [Book]
- Source date:: 2003-08-01
- Finished date:: 2020-01-01
- Cover::
Why did I want to read it?
It is an omnipresent concept in software architecture and even in the data world, with its application to the Data Mesh (this latter part is the one I will focus on).
What did I get out of it?
Definition
Domain-driven design is both a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. (…) To accomplish that goal, this book presents an extensive set of design practices, techniques, and principles. (p. xxi)
Note that:
- It goes way beyond tactical patterns. It’s a whole philosophy around software development.
- It’s not for every project: it’s for those with complex business logic. In fact, DDD philosophy is about making the domain model the driver of the software development process.
Yet the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user. (…) The premise of this book is twofold:
- For most software projects, the primary focus should be on the domain and domain logic.
- Complex domain designs should be based on a model. (p. xxi).
Note that you may still decide to use a model for a domain (Domain Model) that is simple or not make a model domain the center of your application: see Organizing Domain Logic.
Relationship with đź“– Extreme Programming Explained
Regarding Incremental design
While Eric praises it…
This minimalism has been a must-needed antidote to some of the excesses of design enthusiasts (p. xxiii)
…he needs to clarify:
Unfortunately, some of these process ideas can be misinterpreted. Each person has a different definition of “simplest”. Continuous refactoring is a series of small redesigns; developers without solid design principles will produce a code base that is hard to understand or change –the opposite of agility. And although fear of unanticipated requirements often leads to overengineering, the attempt to avoid overengineering can develop into another fear: a fear to do any deep design thinking at all. (p. xxiii)
 Regarding Software documentation
Extreme Programming advocates using no extra design documents at all and letting the code speak for itself (…) This dependence on the code as communication medium motivates developers to keep the code clean and transparent. But code as a design document does have its limits. It can overwhelm the reader with detail. Although its behavior is unambiguous, that doesn’t mean it is obvious. And the meaning behind a behavior can be hard to convey, In other words, documenting exclusively through code has some of the same basic problems as using comprehensive UML diagrams. Of course, massive spoken communication within the team gives context and guidance around the code, but it is ephemeral and localized. And developers are not the only people who need to understand the model. A document shouldn’t try to do what the code already does well. The code already supplies the detail. It is an exact specification of program behavior. Other documents need to illuminate meaning, to give insight into large-scale structures, and to focus attention on core elements. Documents can clarify design intent when the programming language does not support a straightforward implementation of a concept. Written documents should complement the code and the talking (p. 38).
Traditional Layered Architecture
From Buschmann et al.:
(p. 62)
Any element of a layer depends only on other elements in the same layer or on elements of the layers “beneath” it (p. 60).
Upper layers can use or manipulate elements of lower ones straightforwardly by calling their public interfaces (p. 73).
Being “below” the domain layer, [the infrastructure layer] should have no specific knowledge of the domain it is serving. Indeed, such technical capabilities are most often offered as services. For example, if and application needs to send an -email, some message-sending interface can be located in the infrastructure layer and the application layer elements can request the transmission of the message (…) When the scope of a service has been well chose and its interface well designed, the caller can remain loosely coupled… (p. 73)
Refactoring Towards Deeper Insight
A well-worn glove becomes supple at the points where the fingers bend, while other parts are stiff and protective (p. 191)
Other notes
An aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes.