DDD - 1 - A gentle introduction to Domain Driven Design.pdf
1 like1,212 views
The document introduces domain-driven design (DDD) as a methodology aimed at improving communication among stakeholders to address project failures arising from unclear requirements and goals. It emphasizes the importance of understanding business domains and subdomains, the role of domain experts, and the use of ubiquitous language to ensure consistent communication across teams. Additionally, it discusses modeling, bounded contexts, and various integration patterns to manage complexity and foster collaboration in software development.
![References
[1] Vlad Khononov, Learning Domain-Driven Design - Aligning Software
Architecture and Business Strategy, O’Reilly, 2022
50](https://image.slidesharecdn.com/ddd-1-agentleintroductiontodomaindrivendesign-220530084053-db69c6aa/85/DDD-1-A-gentle-introduction-to-Domain-Driven-Design-pdf-50-320.jpg)
DDD - 1 - A gentle introduction to Domain Driven Design.pdf
- 1. A gentle introduction to domain-driven design Eleonora Ciceri - 12 January 2022 1
- 2. The rationale: why domain-driven? (1) Communication issues in projects are often the cause for project failures These issues can manifest themselves in different ways: - unclear requirements - uncertain project goals - ineffective coordination - ineffective effort 2
- 3. The rationale: why domain-driven? (2) Domain-driven design (in short, DDD) focuses on effective communication: What do we gain? Guide decisions according to the business strategy 3 DDD strategic tools Analyze business domain and strategy to foster a shared understanding of the business between stakeholders DDD tactical tools Write code in a way that reflects the business domain, addresses its goals and speaks the language of the business
- 4. Analyzing a business domain 4
- 5. What is a business domain? A business domain defines a company’s main area of activity 5 “sells coffee” “provides courier delivery”
- 6. What is a subdomain? A subdomain is a fine-grained area of business activity The subdomain have to interact with each other to achieve the company’s goal in its business domain 6 business domain (some) subdomains buy real estate hire personnel manage finances sell coffee divides into
- 7. Core subdomain A core subdomain is what a company does differently from its competitors - inventing new products or services - reducing costs by optimizing existing processes 7 Uber Ridesharing Jewelry maker Jewelry design Google Ranking algorithm
- 8. Generic subdomain A generic subdomain is a business activity that all companies perform in the same way - do not provide competitive advantage - no need for innovation or optimization (use what is available!) 8 Jewelry maker Online shop Uber Authc/z
- 9. Supporting domain A supporting domain supports the company’s business without providing competitive advantage 9 Online advertising company Storing and indexing creative materials (banners, landing pages…)
- 11. Solution strategy All subdomains are required for the business domain to work! 11 Core subdomain Generic subdomain Supporting subdomain has to be implemented in-house (if adopted from someone else, it would undermine the notion of competitive advantage, as the company’s competitors would be able to do the same thing we do) cost-effective to buy as off-the-shelf product or adopt an open-source solution (hard but already solved problems) a rapid application development framework will suffice to implement the business logic without introducing complexity (do not require elaborate design patterns)
- 12. How do we identify subdomains? Start from the company’s departments and other organizational units. Then, investigate inner workings and see if a department is composed of finer-grained components 12
- 13. Identifying the domain experts 13
- 14. Who are the domain experts? Domain experts are subject matter experts who know the business that we are going to model and implement in code The software is supposed to solve their problems 14 What they are - knowledge authorities in the business domain - people coming up with requirements - end users What they are NOT - analysts gathering requirements - engineers designing the system
- 15. Discovering domain knowledge: Ubiquitous language 15
- 16. Business problems The software systems we build are solutions to business problems, both at business domain and subdomain 16 business domain/subdomains courier delivery knowledge management clearing subdomain accounting subdomain business problems ship packages in limited time frame optimize information storage/retrieval optimize the execution of financial transactions optimize the shipping process
- 17. Traditional SW development lifecycle: flaws 17 interviews conducted by analysts, without engineers, sometimes without domain experts written documents that become outdated wrong or distorted understanding of problem and requirements wrong solution, or right solution to the wrong problem A chain of translations distills the wrong domain knowledge and leads to the wrong software
- 18. Knowledge discovery To design a software solution, we have to grasp and distill the basic knowledge of the business domain 18 the knowledge belongs to domain experts it is their job to understand the intricacies of the business domain we are not domain experts it is NOT our job to understand the intricacies of the business domain The software has to mimic the domain experts’ way of thinking about the problem Without an understanding of the business problem and the reasoning behind the requirements, our solution may fail to describe a business concept
- 19. Knowledge discovery needs the proper language To grasp and distill the basic knowledge of the business domain, the parties involved need to speak the same language - we do not have to make up the language - we need to use the actual, existing language of the domain 19
- 20. Ubiquitous language Using a ubiquitous language is the cornerstone practice of domain-driven design Idea: if parties need to communicate efficiently, instead of relying on translations, they have to speak the same language 20 software engineer product owner domain expert UI/UX designer All should use the ubiquitous language when describing the business domain
- 21. No technical jargon! 21 “the order can be published only if it has at least one associated record in the customer table” “the advertisement iframe displays an HTML file” “we acquire real-time data using a sensor”
- 22. Formulate statements in the language of business 22 “an advertising campaign can display different creative materials” “an order can be placed only if at least one of the contained items is available” “sales commissions are accounted for after transactions are approved”
- 23. Language consistency: ambiguous terms Ambiguity hinders communication, so each term of the ubiquitous language should have one and only one meaning If a term is ambiguous, replace it with something that is not 23 policy regulatory rule insurance contract
- 24. Language consistency: synonymous terms Two terms cannot be used interchangeably in a ubiquitous language, e.g., user, visitor, administrator, account… Often these synonyms denotes different concepts, e.g., - “visitor” may be used only for analysis purposes in a website, as he is not registered - “account” actually uses the system and its functionality 24
- 25. Discovering domain knowledge: Model of the business domain 25
- 26. What is a model? “A model is a simplified representation of thing or phenomenon that intentionally emphasizes certain aspects while ignoring others” – Rebecca Wirfs-Brock A model is NOT a copy of the real world; it is a human construct that helps us make sense of real-world systems 26 Canonical example: a map is a model that does not represent all the details of our planet, but contains enough data to support its particular purpose, i.e., the problem it is supposed to solve
- 27. Effective modeling All models have a purpose, and an effective model contains only the details needed to fulfill its purpose Just omit unnecessary details and leave only what is needed for solving the problem at hand 27 there are no subway stops on world maps you cannot use a subway may to estimate distances
- 28. Modeling the business domain The business domain model is supposed to: - capture the domain experts’ mental models (i.e., their thought processes about how the business works to implement its function) - include just enough aspects of the business domain to make it possible to implement the required system 28 When solving the arrhythmia detection problem we shall model ECG signals… … not the heart vessels!
- 29. Modeling is a continuous effort The ubiquitous language should be continuously reinforced throughout the project. All the following should use this language: - requirements - tests - documentation - source code Cultivation of a ubiquitous language is an ongoing process. Everyday use of the language will reveal deeper insights into the business domain 29
- 30. Tools for managing the ubiquitous language 30 glossary It maintains nouns (names of entities, processes, roles etc.) It has to be maintained by all team members, not just by architects and team leaders! tests Tests in Gherkin language can capture the ubiquitous language but also to describe behavior (business logic, its rules, assumptions, invariants)
- 32. Context is what gives words a meaning Some words have different meanings depending on the context in which they are used 32
- 33. Squeezing diversified knowledge into the model Suppose we have two experts who do not agree on the ubiquitous language: Seems like we are mixing domain concepts from different contexts. This is why we have to introduce bounded contexts 33 Expert from marketing department “a lead is a notification that somebody is interested in one product” Expert from sales department “a lead represents the entire lifecycle of the sales process”
- 34. Bounded contexts The solution in domain-driven design is trivial: divide the ubiquitous language into multiple (smaller) languages, then assign each one to the explicit context in which it can be applied The contexts in which we apply these smaller languages are called bounded contexts 34 A ubiquitous language in one bounded context can be completely irrelevant to the scope of another bounded context
- 35. Bounded contexts vs Subdomains 35 Subdomain A subdomain resembles a set of interrelated use cases Use cases are defined by: - business domain - system requirements We do NOT define the requirements, that is the responsibility of business Bounded context A bounded context is designed (and choosing its boundaries is a strategic design decision) We decide here how to divide the business domain into smaller, manageable problem domains Relationship between subdomain and bounded context: - Having a one-to-one relationship between bounded contexts and subdomains can be reasonable in some scenarios - In other scenarios, different decomposition strategies can be more suitable: it could be beneficial to use multiple models of the same concept to solve different problems
- 36. A practical example: model for a refrigerator (1) This is a model of a refrigerator: No, it’s not a refrigerator, but it models the refrigerator without copying the real-world entity. It has a purpose – a problem it is supposed to solve 36
- 37. A practical example: model for a refrigerator (2) The problem it solves is checking whether the refrigerator can fit through the kitchen door The cardboard does not look like the fridge, but building a 3D model would not solve the problem more efficiently than the cardboard. Thus, building a 3D would be called overengineering 37
- 38. A practical example: model for a refrigerator (3) The cardboard model, though, cannot check if the height of the refrigerator is adequate. We need a second model for the same fridge: Each model has its bounded context (the cardboard verifying that the base makes through the entry, the tape measure verifying that it is not too tall) 38
- 40. Contracts between bounded contexts Bounded contexts themselves are not independent - a system may be built of components - components have to interact with one another to achieve the system’s overarching goal There are touchpoints between bounded contexts, called contracts or integration patterns 40
- 41. Integration patterns: Cooperation Cooperation patterns relate to bounded contexts implemented by teams with well-established communication or by a single team Partnership. Each team develops its own bounded context, integration is done collaboratively Shared kernel. The same (sub-)model is implemented in multiple bounded contexts. It introduces dependencies between contexts: it has to be applied only when the cost of duplicating code is higher than the cost of coordination 41
- 42. Integration patterns: Customer-Supplier (1) Customer-supplier patterns have a service provider (upstream) and a consumer (downstream) that interact Here teams are independent, and in most cases we have an imbalance of power: either the upstream or the downstream team dictate the integration contract 42
- 43. Integration patterns: Customer-Supplier (2) Conformist. If the upstream does not have motivation to support the downstream needs, it defines the integration contract, defined according to its own model. If the downstream accepts the contract, it is called conformist. Anti-corruption layer. The upstream service has still the power of the relationship. However, the downstream is not willing to conform. Thus, it will translate the upstream bounded model into a model tailored to its own needs. The anti-corruption layer performs the translation, so that the downstream is isolated from foreign concepts 43
- 44. Integration patterns: Customer-Supplier (3) Open-Host Service. Here the upstream wants to provide the consumer the best service possible. The upstream decouples the implementation model from the public interface: it implements its model, but offers a public protocol that is convenient for the consumer (also called the published language) It is also possible to create multiple versions of the published language, to serve different downstream applications or to allow the downstream to migrate to new versions gradually 44
- 45. Integration patterns: Separate ways The last collaboration option is not collaborate at all, e.g., there are teams unwilling to collaborate: - Communication issues: when teams have a hard time collaborating, it is more cost-effective to go separate ways and duplicate functionalities in multiple bounded contexts - Generic subdomains: if the subdomain is generic it is more cost-effective to integrate it locally in each bounded context (e.g., logging: one of the contexts expose it as a service and the other use it) 45
- 46. Context maps 46
- 47. Context map A context map is a visual representation of the system’s bounded contexts and the integrations between them 47
- 48. Why using context maps? For many purposes: - High-level design: a context map provides an overview of the system’s components and its models - Communication patterns: a context map depicts the communication patterns among teams, e.g., which teams are collaborating and which prefer less intimate integration patterns - Organizational issues: a context map can give insight into organizational issues. E.g., what does it mean if the consumers for a certain upstream team all resort to implementing an ACL? - Documentation: sharing the effort of updating the context map over different teams helps in building a shared documentation 48
- 49. References 49
- 50. References [1] Vlad Khononov, Learning Domain-Driven Design - Aligning Software Architecture and Business Strategy, O’Reilly, 2022 50