Domain Driven Design Flashcards
Describe domain-driven design
Domain-Driven Design or DDD is an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain. The name comes from a 2003 book by Eric Evans that describes the approach through a catalog of patterns.
What are the three core principles of domain-driven design?
- Focus on the core domain: Before you begin coding, talk to people who work in that domain. They can help you to define all of the processes, procedures, and terminology of that domain. For example, if you are designing software to manage retail inventory, talk to the people who manage the store inventory rather than employees in HR or finance.
Describe the key domain-driven design term: Domain logic
Domain logic: Also called business logic. This is the purpose of your model and software design. The design is based on the logic of real-world business rules that are translated to programming code.
Describe the key domain-driven design term: Design patterns
Design patterns: If there is existing code that solves a problem similar to one you’re working on, adapt it for your use. Don’t try to reinvent the wheel every time.
Describe the key domain-driven design term: Context
Context: The setting or environment that determines the meaning of a word, action, or feature within the software domain. For example, in a certain context it may make more sense to use an “Apply” button instead of a “Save” button.
Describe the key domain-driven design term: Bounded context
Bounded context: Large projects usually have many models that need to be integrated. A context boundary defines the logical frame in which a model can evolve. This helps other teams understand what they have to do to make their models valid when they are added to others.
Describe the key domain-driven design term: Context mapping
Context mapping: A document, graph, or diagram that outlines the relationships among multiple bounded contexts. The map shows each context’s language, independent implementation, and the interface used to communicate with other bounded contexts.
Describe the key domain-driven design term: Entities
Entities: An entity is a domain object that is defined by its unique identifier rather than by attributes. For example, a person buys a ticket to see a movie. The person is an entity because the unique identifier defines who that person is regardless of changes to hair color, weight, height, and so on.
Describe the key domain-driven design term: Value objects
Value objects: An unchangeable object that has attributes, but no distinct identity. For example, you buy a movie ticket that does not include assigned seating. All seats in the theater are the same. The seats are bolted down and can’t be moved, but your ticket lets you select any available seat. In this context, the seat is a value object.
Understanding domain-driven design
According to DDD, we should not construct a unique Domain Model that keeps all the views as separate models. Instead, the whole application domain is split into smaller domains, each with a separate model. These separate domains are called Bounded Contexts. Each domain is characterized by the language used by the experts and used to name all the domain concepts and operations. Thus, each domain defines a common language used by both the experts and the development team called a Ubiquitous Language. Translations are not needed anymore, and if the development team uses C# interfaces as bases for its code, the domain expert is able to understand and validate them since all the operations and properties are expressed in the same language that’s used by the expert.
What is a DDD_Aggregate
Aggregate is a pattern in Domain-Driven Design. A DDD aggregate is a cluster of domain objects that can be treated as a single unit. An example may be an order and its line-items, these will be separate objects, but it’s useful to treat the order (together with its line items) as a single aggregate. An aggregate will have one of its component objects be the aggregate root. Any references from outside the aggregate should only go to the aggregate root. The root can thus ensure the integrity of the aggregate as a whole.
