## Notes The book *Domain Driven Design* was written by [[Eric Evans]] as a way of discussing ideas about modeling real-life problems to software development. The book was released 15 April 2003. ## Projects Described The author reflects on three projects that followed domain-driven design in various amounts, and describes where the projects succeeded and failed. The first project was a web-based trading platform that was successful out of the gate. Even though the product was a success, it could not scale beyond the initial code because it lacked thought out design and scalability. Another project approached design mindfully and was able to add additional features with ease and continued to stay a success. The last system had good domain modeling, but there was a disconnect between developers that ultimately caused it to derail. ## Things that Surprised Me - That domain-driven design is not only about "collecting nouns" but also gathering business rules and activities - "Knowledge crunch": an activity where software modelers, business experts, and subject matter experts come together to hash out the design of the system - A business rule such as "allow overbooking of a booking application" could be hidden in code logic, but would be better refactored as a **Domain Object** - When the author talked about different team members using different terminology to describe the same thing, it reminded me of Cigna where the project managers and developers insisted and using different terms - The team should consistently use the domain model terminology until it makes sense to everyone - UML diagrams cannot convey - the meanings of concepts it represents - what they are meant to do - The model is not the diagram - Documentation should not duplicate code; it should give more meaning ## Building Blocks From [Domain Driven Design - Log Rocket](https://blog.logrocket.com/typescript-domain-driven-design/) ## Building Blocks From [Domain Driven Design - Log Rocket](https://blog.logrocket.com/typescript-domain-driven-design/) Model Driven Design expresses models with - Services - Entities - Value Objects Entities - access through Repositories - encapsulate with Aggregates - act as root of Aggregates Value Objects - encapsulate with Aggregates - encapsulate with Factories Aggregates encapsulate with Factories Aggregates access with Repositories ## Layered Architecture 1. UI 2. Application 3. Domain 4. Infrastructure ## Differentiation - A **Service** is something done at the request of a client - An **Entity** is something that is tracked through different states and implementations - A **Value Object** is an attribute that describes the state of something else - **Modules** reflect concepts of the domain; has high-cohesion and low-coupling ## Associations When starting to define the models in a domain, it is easy to get caught in making them bi-directional. In addition, this bidirectionality makes it hard to understand the context. Making associations more understandable: - Define the direction of association - Add a qualifier, which reduces multiplicity - Eliminate non-essential associations ### Example - George Washington was a President of the United States - It is known that George Washington is associated with the United States; one does not need to ask "of which country was George Washington the president?" - George Washington was the president of the United States at a specific time - This is the qualifier ## Entities These have a consistent identity even though it goes through transformations and has different representations. > ENTITIES are defined by their identities. Attributes are attached and change. Therefore, strip the ENTITY object’s definition down to the most intrinsic characteristics, particularly those that identify it, or are commonly used to find or match it. Separate other characteristics into other objects associated with the core ENTITY. Entities have conceptual responsibilities they fulfill by coordinating operations of objects they own. ## Value Objects Transient, often used collection of attributes that are not integral to a thing's identity, but are used often enough to warrant grouping them together. An Address details shouldn't be part of a Person, but it makes sense to group street, city, country into an Address object/record. However the Address analogy could also be an **Entity** if the domain is about delivering mail or electricity. **Value Objects** should generally be immutable unless - Properties change often - Creation/deletion is expensive ## Services Typically activities or actions with the following characteristics - Stateless - Not tied to any model - Uses models ### Relationship to Layer - An email service would belong in the infrastructure layer - Application layer service would order the notification service - In a banking app, issuing a transfer would be a domain layer service - Exporting financial transactions to a PDF would be an application layer service