Domain Driven Design - Eric Evans book notes
Domain Driven Design book - Eric Evans (2003)
I love this book. So well written. Espouses good principals and practices which still apply today. Good examples to follow and learn from. (kindered spirit)
Introduction
domain - the subject area, area of interest e.g. the domain of a restaurant system involves real people booking reservations at restaurants
- to create valuable software you need to understand the domain its for, models can help focus on what's important out of that large domain
The domain model is not a particular diagram; it is the idea that the diagram is intended to convey. It is not just the knowledge in a domain expert’s head; it is a rigorously organized and selective abstraction of that knowledge.
The domain model is the idea that the diagram is intended to convey; loosely representing reality to a particular purpose.
Developers have to steep themselves in the domain to build up knowledge of the business.
Three basic uses for domain model:
1. the model dictates the form of the design at the heart of software
2. the model is the backbone of a language used by all team members; can easily communicate with domain experts
3. the model is distilled knowledge; the way the team organizes knowledge and what's important
Chapter 1 Crunching Knowledge
The author goes though an example of flushing out the domain model for a Printer Circuit Board design.
Using entity relationship and sequence diagrams (models) over multiple sessions with domain experts the author shows us how to create and refine the models.
To focus exploration, the author said "we limited ourselves, to studying one particular feature. A “probe simulation” would trace the propagation of a signal ..".
- denis: these are basically user stories i.e. a particular feature for the user
Interesting how the nature of the multiple discussions with experts change from very basic ideas and understanding notation early on, to flushing out terms and meanings and deeper models. So rigor and knowledge deepened over tine.
Then with enough model (after a few part time days) the author built a functioning prototype with mock data. Which then led to more feedback
- denis: very agile
Over time as more features were added they used the model as the means to communicate and understand. It resulted in changes to the model as the model and code co-evolved.
- denis: this is important, too many times once model is coded its abandoned, start with the model
Effective domain modelers are knowledge crunchers. They try one organizing idea after another, searching for the simple view that makes sense of the mass.
The team and domain experts work together to build the model. The engineers must learn the domain.
- denis: iterating, collaborating, learning the domain, understanding the principals, applying the rigor, feedback loop and prototypes. Wow, so well written and still so relevant almost 20 years later.
A domain model is more than just entities, more than just "find the nouns”, it includes identifying business rules and activities and other concepts.
Deep vs superficial models. Great example at end of chapter where the team were modeling the Cargo shipping domain (identifying entities: cargo, voyage and overbooking rule, loading and unloading) but that was not actually capturing what the customers business was. It was the superficial model. The deeper model was that the customers business was more of a series of transfers to responsibility to various owners and tracking that. This changed their model profoundly.
Knowledge crunching is an exploration, and you can’t know where you will end up.
Chapter 2 Communication and Use of Language
The domain model can be the core of a common language for a software project. The model is the set of concepts built up in the heads of people on the project, with terms and relationships that reflect domain insight.
A model can be viewed as a language.
It is a serious problem when the language used on a project is fractured. The overhead cost of all the translation, plus the risk of misunderstanding, is simply too high.
- denis: for sure, I've seen the problems this caused, we lost about a month on a project because it never established the common concepts and language and models and had to restart and do that.
The author says:
- there has to be commitment by the team to rely on the model; it becomes integral to everything the developers and domain experts do together
- use the model as the backbone of a language
- experiment and refactor to fix gaps and inaccuracies; gaps and misunderstandings will be identified and the model updated
- play around and experiment with entities and their interactions, try alternatives
- test the model by walking through scenarios
If sophisticated domain experts don’t understand the model, there is something wrong with the model.
The book provides a good example of good domain modeling discussion to understand requirements and one less good (too focussed on low level implementation details and missing important model entities such as Itinerary and RouteSpecification)
A lot of object model diagrams are too complete and, simultaneously, leave too much out. Every attempt I’ve seen to use the code generation capabilities of the modeling tools has been counterproductive
- denis: 100% agree! definitely true people can and did go overboard on model details, agree with authors recommendation to keep diagrams simple and informal especially at the beginning: focus on the problem domain not the notation or technical details
Always remember that the model is not the diagram. The diagram’s purpose is to help communicate and explain the model.
Chapter 3 Binding Model and Implementation
Domain-driven design calls for a model that doesn’t just aide early analysis, but is the very foundation of the design. ..the design is now a direct outgrowth of the carefully considered model
- denis: there is no separate "analysis model", there is only 1 model which informs everything else
- denis: although the author says object oriented design and languages are best suited to implement the model concepts (binding the model to implementation), domain driven design is useful and used when modeling microservices and frontend state (in functional languages) and react apps and this post. The 2nd last post has ideas about folder structure based on DDD, but there are lots of opinions on folder structure. The latter advocates writing javascript classes corresponding to the domain (p.s. re "Domain Model is all of the nouns in a system and their relationships to each other." DDD is more than that, it's also business rules and activities). Why not instead create hooks for the entities in the domain. If you want a Customer then use the useCustomer hook, likewise useInvoice hook. Encapsulate the state data and the actions on it in its hook.
The author gives an example of where the modelers were not allowed to implement the model (because that was simpler work). It resulted in implementations which strayed from the model and in fact did not use it at all. The modeler must be part of the implementation process to understand constraints of implementation and help with the correctness of the implementation. With MODEL-DRIVEN DESIGN, a portion of the code is an expression of the model, so changing that code changes the model
- denis: I saw this happen myself years ago on a large insurance project I was on. Two modelers spent over a month developing a Business Object Model but it was too complex for us to implement and parts of it were abandoned. Lesson: model and implement together (pretty easy nowadays with agile teams)
Chapter 4 Isolating the domain
Isolating the domain implementation is a prerequisite for a domain-driven design.
A common way to do this is to layer the architecture e.g. like these layers
- User Interface; show info to user and interpret commands
- Application Layer; coordinates tasks and delegates to Domain Layer
- Domain Layer; represents concepts of business and business rules. the manifestation of the model including entities and business logic
- Infrastructure Layer; persistence, auth/authz, messaging
- denis: with spa frontends and microservices you have layering on both the FE and the Backend (BE). A goal would be to have a robust domain layer on the BE, it's user interface is a restful api receiving and returning json (build api by design by contract)
- but frontends also have state and complexity and it makes sense to implement elements of the domain model on the frontend too (e.g. same language, entities, ui rules, hooks, folder structure)
Chapter 5 A Model Expressed in software
Connecting model and implementation has to be done at the detail level. The following are building blocks:
- Entities: something with continuity and identity, has different states
- An object defined primarily by its identity is called an “ENTITY”
- Entities have lifecycles and can change their form and content
- e.g. a bank deposit transaction, a customer, a restaurant, designate seat on a plane, airline reservation number. ...but it also depends on what's important in the model
- If necessary generate the id but could reuse e.g. SSN
- Value objects: describes state of something else
- describes what things are, not who they are
- often attributes of Entities e.g. customer address
- often passed as parameters between calls, frequently transient
- Services: something which will be done for a client on request; actions or operations; defined in terms of what it can do for the client, a verb
- Some concepts from the domain aren’t natural to model as objects. They're not Entities or Value Objects. Don't try to force an operation onto an Entity if it does not belong there.
- when an operation is actually an important domain concept, a SERVICE forms a natural part of a MODEL-DRIVEN DESIGN.
- Services should be stateless
- A good example given is funds transfer. It involves 2 accounts (giver and receiver) debit one and credit the other and ensuring the transaction is atomic. Doesn't really belong on Account entity. Is more a Service which tells giver account to debit, receiver account to credit and then commits.
- Yes common services are infrastructure or technical services (not in business domain per se) but can also be on the domain
- But some actions belong on Entities, not everything needs to be a service
Comments
Post a Comment