Domain Driven Design
Download as PPTX, PDF1 like251 views
- DDD is designed around an onion architecture for loose coupling between domains, applications, and infrastructure - Event storming helps gather structured information to understand the business domain and requirements - Entities have unique IDs and are mutable while value objects describe entities and are immutable - Aggregates group related entities and value objects together, with the root entity accessible from outside - Invariants, anti-corruption layers, and domain events help model the business logic and handle changes
![Subdomain
Example
High level requirements specification
Notifications for an existing Payments
System
Based on specific
business rules
Different mailing
options [Email and
SMS]
Customisable
message content
Notification tracking
Logging and
reporting](https://image.slidesharecdn.com/domaindrivendesign-191201181011/85/Domain-Driven-Design-11-320.jpg)
Domain Driven Design
- 1. Domain Driven Design: Fundamentals By Hannah Farrugia
- 2. Lesson 1 What is DDD? What makes it valuable? Goal definition DDD principles Modelling paradigms Onion architecture
- 3. What is Domain Driven Design? • A software design tool and a way of thinking that bases domain modelling on a business driven concept • A design that strives on communication between domain experts and software architect(s) • A centralised knowledge-rich design • An iterative, adaptive process of discovery and challenges that lead to learning and continuous improvement
- 4. Why pursue DDD? • Focuses on the core problems that the system is expected to solve • Beneficial for complex domains and business areas • Manages to organise and simplify object models in ways that are strategic and focussed • Creates a clear separation between areas • Encourages clear and common understanding between stakeholders • Based on Agile principles
- 5. Goal definition : • To simplify the domain complexities through a ubiquitous language, define system boundaries that focus on specific business problems and keep a focus on the business logic residing in the core domain.
- 6. DDD Principles As Eric Evans says: A 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. A diagram can represent and communicate a model, as can carefully written code, as can an English sentence. Uncovers key business drivers through constant questioning Unification of jargon that leads to a Ubiquitous Language Works with Collaboration/Experimentation/Adaptation Depicts the agreed knowledge Boundaries will be defined… And redefined
- 7. • In object-oriented programming, the open/closed principle is applied. This states that "software entities should be open for extension, but closed for modification"; that is, such an entity can allow its behaviour to be extended without modifying its source code. • Every method should be either a command that performs an action, or a query that returns data to the caller, but not both. In other words, asking a question should not change the answer. More formally, methods should return a value only if they are referentially transparent and hence possess no side effects -Meyer, Bertrand Object Oriented Design and Command Query Responsibility Segregation Agile supports DDD • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan -Agile Manifesto Iterative, Agile Creating designs that can easily be prototyped to involve stakeholders earlier and demonstrate how the model ties into the functional software: • This provides feedback at the initial stages of the design • It surfaces gaps from requirement analysis or design • Stakeholders feel more involved in moulding the final version. Prototyping Modelling paradigms:
- 8. Summary: • DDD is a way of thinking that creates a design based on the business needs of the organization • Its value is derived from the simplification of complexities in the domain • The goal is to focus on business contexts individually and align knowledge to one source of truth • DDD is an iterative process that refines the model through learning • Goes hand in hand with CQRS and OOD, makes it easy to prototype during iterations
- 9. Domain Services Onion Architecture definition : Domain Model Application Services Domain Services User Interface •Normally there is one onion architecture per bounded context •Outer layers depend on internal ones, therefore the dependency flow goes inward •The infrastructure resides outside of this layer
- 10. Domain Services Onion Architecture definition : Domain Model Application Services Domain Services User Interface Triggers for business logic Core objects and business rules • Ports • Adapters • Interfaces with ORM, search engines, messaging interfaces The layer that surfaces the functionality to the user
- 11. Subdomain Example High level requirements specification Notifications for an existing Payments System Based on specific business rules Different mailing options [Email and SMS] Customisable message content Notification tracking Logging and reporting
- 12. Strategic Design What we did, what we do Our amazing products Our awesome ideas Marketing data and our estimation 1 Before starting Introduction 2About us 3Our portfolio 4New proposal 5Analysis Eric Evans - Domain Driven Design : Tackling complexity in the heart of software
- 13. • Ask for the definition of the important words, but most importantly understand how they form part of the business process • Complexities will come out of the conversation with domain experts • Define what feeds into the requirements, the output that is expected from them and any constraints that you should be aware of
- 14. Context Maps • Maps the system areas and relationships between them • Each one has its own language, but can be shared or coupled with other contexts • Can be based on team structures • Boundaries are created between contexts to create focus on specific areas • Bounded contexts =/= sub domains • Bounded contexts within the scope of DDD, refer to the domain layer, although they can still have an independent infrastructure
- 15. Some more Requirements • Fraud detection system – Create a notification for every case that is deemed fraudulent • Notify the customer when their transaction is a chargeback • Notify the customer when their spending reaches the daily limit • Send the user a notification when they activate their portal account
- 16. The organization behind it • The bigger teams within the organization split the responsibilities between the Operations and Customer Support, the account management and boarding team • Exceptions are handled by the dispute management team • Fraud and analytics are a small team that have a large responsibility
- 17. Object identificatio n Triggers for our notifications are based on: • Amounts per card brand • The cases created by the fraud system rules • The status of a chargeback and • The status of the customer web account
- 18. What about the ubiquitous language?:
- 19. Summary: • DDD is typically designed based on an onion architecture for loose coupling between domains, applications and the infrastructure • Event storming is a great way to focus on the business behind the domain and to gather information in a structured way • Requirements for our business case, constraints and rules that apply • Evan’s strategic design map • Context map and business case contexts • Requirements from an object point of view • Translators can be needed to protect the ubiquitous language of a domain
- 21. Tactical Design What we did, what we do Our amazing products Our awesome ideas Marketing data and our estimation 1 Before starting Introduction 2About us 3Our portfolio 4New proposal 5Analysis Eric Evans - Domain Driven Design : Tackling complexity in the heart of software
- 22. Shared Kernels •Based on collaboration •Changes will need every party involved •They should be kept to a minimum •Shared Kernels will probably be the result of either a core or generic domain •Technology might require rework if there are conflicts in existing contexts
- 23. Entities Questions you can ask to test if an object is an entity: Do two similar objects (like a person), need to be distinguishable? If you have two instances of the same object , can one replace the other? Is there a unique identifier for the object? Entities are represented by continuity and identity Multiple instances of an entity still point to the same conceptual identity Defining an entity depends on the business context Most importantly, remember that entities are mutable
- 24. Aggregate Roots • Entities within the same aggregate are cohesive An encapsulated structure with a group of entities The root can be referenced by objects outside of the boundary, but other objects within the boundary cannot be referenced
- 26. Value Objects SEARCH • VOs describe entities. They have no conceptual identity, and yet an entity is not quite complete without these descriptors • VOs are interchangeable • They can be passed in a message when being transferred from one object to another • They are Immutable, so they cannot be changed except by full replacement • They normally form a conceptual whole • There are school of thoughts that classify types differently
- 28. Summary: • Tactical design incorporates structuring domain details in entities, value objects and aggregates • Entities have their own ID and are mutable. • Aggregates hold groups of objects inside of them – remembering that objects that are not part of the root, but part of the aggregate, cannot be referenced by objects outside of the aggregate. • Value objects describe entities and are immutable
- 29. Invariants • A type of validation • Maintained by an entity • Consistency rules satisfied whenever data changes • Involved in relationships between members of an aggregate • An object within an aggregate must satisfy all of the invariants
- 30. Anti Corruption Layer The Power of PowerPoint - thepopp.com30 Helps prevent corruption of information It's necessary if another model is structured differently IT interacts with different bounded contexts, foreign systems, legacy apps or databases. In practice, there may still be the need to talk to a monolith system, An ACL normally carries design patterns like facades, adapters and translators
- 31. • Domain events are a way to describe activities/state changes that occur in the system, • Objects within the domain that raise the event don’t worry about what happens after the event is raised • Domain events require handlers . • Handlers can be thought of as listeners • Events always represent things that occurred in the past • Typically, a domain event will output the timestamp of when the event occurred. • Domain events do not have any side effects Domain Events
- 32. • Factories create and reconstitute complex objects. They act as an interface that create instances of complex objects, entities and aggregates. • The outcome of an operation can entail the creation of an object. • The creation of objects is therefore handled through a factory that can create aggregates and enforce their invariants. (for implementation information refer to Factory patterns in Gamma et al. 1995) • Repositories can be thought of as an in-memory collection interface (with more elaborate querying capability). • Acquiring references to existing domain objects can be done via query methods • Repositories store and are used to find persistent objects • Their purpose is to keep the domain model business focussed. Factories and Repositories in DDD
- 33. Specification s* SEARCH • A specification pattern states the constraints on the state of an object • Used to test if an object satisfies certain criteria. • Sometimes, complex business rules do not fit the responsibility of a particular entity or value object. • To solve this dilemma, the rule can be implemented as a specification object or objects (including AND, OR, NOT etc). • When a factory creates an object, it can also take the responsibility of configuring its specification. *This term was coined by Evans and Fowler. Detailed information can be found in this document https://www.martinfowler.com/apsupp/spec.pdf
- 34. . Service implementation • Domain Services - A service can be defined as the realisation of a process. A domain service is "an operation to the model as a standalone interface" that "is not a natural responsibility of an Entity or a Value Object". • Application Services - These interact with other systems, listen for incoming messages and decide whether or not to use an infrastructure service. • Infrastructure Services - Here, an infrastructure-related action will happen. Services Domain Services Domain Model Application Services Domain Services User Interface Notification system
- 35. • Geared towards database requirements, not business requirements • A domain model that is simply reduced to getting and setting, holding little to no business logic and not really reflecting the events and behaviours that trigger or impact business rules • A model where the business rules are stored in the application (or other) layers • Anemic models result into lots of time wasted into mapping the objects to the persistence layer https://martinfowler.com/bliki/AnemicDomain Model.html Anemic Domain Model • Domain experts will probably not be well- versed with the DDD framework. • Keep yourself updated with DDD (references available in the references slide) Being influenced by the current system • The process for DDD is meant to be agile. • Taking a big bang approach will go against the iterative model Taking a big bang approach DDD Anti-Patterns Keep Calm and Think.
- 36. Lessons Learnt 1.DDD is situational: • System complexity makes a difference • Will the system need frequent changes? • You're always trying to solve a specific problem. • Vernon’s scorecard: http://www.informit.com/articles/article.aspx?p=1944876&seqNum=2 (scroll down) 2. Rebuilding and changing at the same time should be avoided: • Lost focus • Reengineer first, DDD last • Changing is expected • DDD assumes that the business use cases are static 3. If you're changing an existing system to DDD: • Take the bubble approach - "Getting Started with DDD When Surrounded by Legacy Systems " - Evans http://domainlanguage.com/ddd/surrounded-by-legacy-software/ • Keep previous test cases
- 37. References and Resources Type Source Why it's useful When you should read it Book Domain-Driven Design: Tackling Complexity in the Heart of Software From https://www.amazon.com/Domain-Driven- Design-Tackling-Complexity- Software/dp/0321125215/ref=sr_1_1?keyw ords=Domain- Driven+Design%3A+Tackling+Complexity+i n+the+Heart+of+Software&qid=155913458 7&s=books&sr=1-1 This is the DDD bible If you haven't read it, you should read it now. (Otherwise you can use it like a DDD- Dictionary). Book implementing Domain-Driven Design by Vaughn Vernon From https://www.amazon.com/dp/0321834577 /ref=emc_b_5_i A very good book that explains DDD, it's good to get some additional information You've read Evan's book, but you're looking for different explanations of the same things 15 essays in one pdf https://leanpub.com/ddd_first_15_years There's some eye- opening ideas here, and some really genuine recollections of DDD experiences You've started a DDD project and realised that DDD has some utopian concepts. Reading about other people's challenges will make things easier to process. Website https://martinfowler.com/tags/domain%20dr iven%20design.html If there are some DDD concepts that are unclear, explanations here are very grounded You need a break from books, we all do. A bite-size article is a nice break from books. So you want more?, Check out this mega list (it isn’t mine, but I've used it) - it's pretty updated!: https://github.com/heynickc/awesome-ddd
- 38. Summary: • Invariants – Conditions that are always true and never change • ACL – Protect your domain from corruption • Domain Events – specific to domain layer and do not have any side effects • Factories and repositories – These take care of the creation and storage of objects • Specifications – A place where complex business rules that don’t fit in one specific object can reside • Services – Domain, application and infrastructure services • Anti patterns • Common lessons
Editor's Notes
- #15: *Context maps represent the business situation and represent a map of each area of the system and the links between them. Initially, designing context maps start with fuzzy relationships then move towards more established and clear ones that eventually can be separated with boundaries *Each context has its own language, but can be shared through a shared kernel with other contexts, or they can even be separately coupled. So Within each context, there is general consistency, logical unification and focus on the domain *Contexts can be derived from the team structures or from a certain part of the code You can avoid splinters by enabling continuous integration. Eric Evans mentions these specific techniques: Reproducible merge/build technique Automated testing Rules that limit the lifetime for unintegrated changes • Boundaries are created as part of the learning process and can often be identified during event storming and design activities During these activities, you will realise that boundaries can be placed between different context based on differences that arise as a result of object interaction, language or even differences in the team or teams that are responsible for the context* Communication between bounded contexts can occur via an anti-corruption layer or microservices based on whether domain events play a part of the design- We will go into further details about these interactions as progress with the course material • *It's important to note, that* Bounded contexts are not necessarily equal to sub domains. Sub domains belong to the problem space whilst bounded context belong to the solution space. For example if a project requires a new system feature on an existing monolith, the new functionality could be extracted to a separate bounded context with an ACL • Creating bounded contexts help to decouple different complex areas. This helps with mapping out and designing independent models Bounded contexts have their own onion architecture (with shared elements) and can have their own schema - It's important to understand that within DDD, bounded contexts specifically refer to the domain layer even though each BC could have its own separate and independent architecture
- #21: Based on the requirements and relationships we've seen with the domain so far, we can conclude that there are four bounded contexts and one shared kernel that impact our notification system The context of chargebacks has a relationship with the transactions context, however it does not directly access the context itself. Furthermore the team does not work on the transactional information, since these fall under the responsibilities of the operations team. Similarly the fraud and analytics team focus on rule based systems that detect fraud. Their roles are based on security prevention and fraud system maintenance. The customer and accounts department are in charge of business development and customer boarding. They do, however, register customers for specific cards and create branding strategies for the branding products. Like the customer and accounts context, the operations team require constant relation with the card brands that are related to the respective transactions, since they interface with the card suppliers and card schemes on a daily basis. Any updates to the card product that are noted during operations are communicated directly to the customers and accounts team. Also, the customer and accounts team , along with the operations team, constantly communicate features so that reports and production maintenance accommodate these features. One such feature is the spending threshold, which is relevant to our notification system. This creates a shared context, or rather a shared kernel based on the cards entity The typical nature of shared kernels are described in the next slide
- #37: *Context maps represent the business situation and represent a map of each area of the system and the links between them. Initially, designing context maps start with fuzzy relationships then move towards more established and clear ones that eventually can be separated with boundaries *Each context has its own language, but can be shared through a shared kernel with other contexts, or they can even be separately coupled. So Within each context, there is general consistency, logical unification and focus on the domain *Contexts can be derived from the team structures or from a certain part of the code You can avoid splinters by enabling continuous integration. Eric Evans mentions these specific techniques: Reproducible merge/build technique Automated testing Rules that limit the lifetime for unintegrated changes • Boundaries are created as part of the learning process and can often be identified during event storming and design activities During these activities, you will realise that boundaries can be placed between different context based on differences that arise as a result of object interaction, language or even differences in the team or teams that are responsible for the context* Communication between bounded contexts can occur via an anti-corruption layer or microservices based on whether domain events play a part of the design- We will go into further details about these interactions as progress with the course material • *It's important to note, that* Bounded contexts are not necessarily equal to sub domains. Sub domains belong to the problem space whilst bounded context belong to the solution space. For example if a project requires a new system feature on an existing monolith, the new functionality could be extracted to a separate bounded context with an ACL • Creating bounded contexts help to decouple different complex areas. This helps with mapping out and designing independent models Bounded contexts have their own onion architecture (with shared elements) and can have their own schema - It's important to understand that within DDD, bounded contexts specifically refer to the domain layer even though each BC could have its own separate and independent architecture
- #38: *Context maps represent the business situation and represent a map of each area of the system and the links between them. Initially, designing context maps start with fuzzy relationships then move towards more established and clear ones that eventually can be separated with boundaries *Each context has its own language, but can be shared through a shared kernel with other contexts, or they can even be separately coupled. So Within each context, there is general consistency, logical unification and focus on the domain *Contexts can be derived from the team structures or from a certain part of the code You can avoid splinters by enabling continuous integration. Eric Evans mentions these specific techniques: Reproducible merge/build technique Automated testing Rules that limit the lifetime for unintegrated changes • Boundaries are created as part of the learning process and can often be identified during event storming and design activities During these activities, you will realise that boundaries can be placed between different context based on differences that arise as a result of object interaction, language or even differences in the team or teams that are responsible for the context* Communication between bounded contexts can occur via an anti-corruption layer or microservices based on whether domain events play a part of the design- We will go into further details about these interactions as progress with the course material • *It's important to note, that* Bounded contexts are not necessarily equal to sub domains. Sub domains belong to the problem space whilst bounded context belong to the solution space. For example if a project requires a new system feature on an existing monolith, the new functionality could be extracted to a separate bounded context with an ACL • Creating bounded contexts help to decouple different complex areas. This helps with mapping out and designing independent models Bounded contexts have their own onion architecture (with shared elements) and can have their own schema - It's important to understand that within DDD, bounded contexts specifically refer to the domain layer even though each BC could have its own separate and independent architecture