Domain-Driven Design A pragmatic approach (Eduard Ghergu) (z-library.sk, 1lib.sk, z-lib.sk)

📄 File Format: PDF

💾 File Size: 3.6 MB

📖 Read Online ⬇️ Download

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

📄 Page 1

(This page has no text content)

📄 Page 2

Domain‐Driven Design A pragmatic approach Eduard Ghergu, Ph.D. This book is available at https://leanpub.com/ddd-a-pragmatic-approach This version was published on 2025-07-09 This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do. The author generated this text in part with GPT-3, OpenAI’s large-scale language-generation model. Upon generating draft language, the author reviewed, edited, and revised the language to their own liking and takes ultimate responsibility for the content of this publication. © 2022 - 2025 Eduard Ghergu, Ph.D. https://www.professional-programmer.com

📄 Page 3

Tweet This Book! Please help Eduard Ghergu, Ph.D. by spreading the word about this book on Twitter! The suggested tweet for this book is: New book: Domain-Driven Design Demystified! Learn DDD patterns, Clean Architecture & microservices alignment. Perfect for architects & senior devs. Get it: [https://leanpub.com/ddd-a-pragmatic-approach] #DDD #SoftwareArchitecture #DevBooks The suggested hashtag for this book is #Tweet This Book!. Find out what other people are saying about the book by clicking on this link to search for this hashtag on Twitter: #Tweet This Book!

📄 Page 4

To my lovely and supportive family!

📄 Page 5

Contents Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Why Domain-Driven Design? . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 What is Domain-Driven Design? . . . . . . . . . . . . . . . . . . . . . . . . . 3 Why do we need Domain-Driven Design? . . . . . . . . . . . . . . . . . . . 5 Domain-Driven Design Building Blocks . . . . . . . . . . . . . . . . . . . . . 7 Domain [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Model [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Ubiquitous Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Bounded Context / Context Maps . . . . . . . . . . . . . . . . . . . . . . . 9 Domain-Driven Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . 11 The E-Commerce Domain-Driven Design Sample . . . . . . . . . . . . . . 13 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Requirements and Modelling [12] . . . . . . . . . . . . . . . . . . . . . . . . 14 The Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 https://www.professional-programmer.com

📄 Page 6

Introduction As an approach to software architecture, Domain-Driven Design (DDD) has gained popularity in recent years due to the increasing use of microservices. From the architect’s point of view, the main reason for this is that structuring software around bounded contexts and aggregates is perfect for microservice specialization. Simultaneously, stakeholders and users benefit from a consistent orien- tation to the domain’s expertise as well as a ubiquitous language that helps project the company’s business intricacies into the source code. This book does not introduce any new concepts; instead, it attempts to concisely summarize the essence of DDD, providing a crash course on the fundamentals.

📄 Page 7

Why Domain‐Driven Design? Because we need a way to eliminate the following: • Late Delivery - Almost all of us have experienced or are still experiencing late delivery due to unclear requirements, a last-minute customer change of mind, or other reasons unrelated to the development team. • Stripped-down functionality - In some cases, we will focus on what is needed and remove some requirements or functionalities due to time or price constraints. • Not aligning with customer needs - Sometimes, there are misunder- standings, and the final product does not meet the customer’s expecta- tions. • Complicated changes - Changes can sometimes be complex due to the existing structure. • Hard-to-fix, time-consuming bugs - As long as the application logic is implemented in more than one functional component (a violation of the Single Responsibility Principle - SRP[1]), any change to the functionality is risky without a clear understanding of the business requirement. Ad- ditionally, if the model to be changed is used by multiple modules (for example, the same Customer is used in Orders, Payments, Shipping, etc.), any new requested functionality for a module will have a direct impact on the others that share the same model or functionality. • Functionality is spread across many locations - Usually, there is a tight coupling between different application layers; various “entities,” if defined, are simply objects[2] with a state (members, properties), but they lack business logic, which is often delegated to external components such as services, managers, or ORM-related classes. Ultimately, the logic for a specific feature can be found in controllers, managers, services, and other related components. • Many other issues - There are many other issues related to violations of software design principles and practices.

📄 Page 8

What is Domain‐Driven Design? It is a design methodology defined by Eric Evans in his seminal book Domain- Driven Design: Tackling Complexity in the Heart of Software (Addison-Wesley Professional, 2003). This approach to software development enables teams to manage software construction and maintenance effectively in complex problem domains. It also emphasizes the importance of understanding the business domain to implement the application effectively. However, despite its obvious substantial advantages, it’s not a silver bullet and cannot be used everywhere or under any condition. It primarily consists of recommendations, best practices, building blocks, and patterns that can be utilized to address some of the common development challenges that often arise during application construction. As software developers, we need to “translate” the real-world business domain into a form that can be used to create the application’s code — a domain model. This is a crucial aspect of our software design. It will also serve as a communication channel between domain experts and the software development team. Domain-Driven Design favors the Separation of Concerns (SoC) design principle [3]. The different parts of an application get separated, so we are trying to isolate functionality into very specific modules to avoid cluttering the code and having unnecessary dependencies that are hard to change and maintain. Typically, a complex problem may be broken down into smaller problems that are much easier to solve (Divide et Impera strategy). Similarly, a complex business domain can be “split” into subdomains with defined roles and goals, which are easier to model—an application of SoC [3]. Think about an ERP system: How can we best design and implement it? We might have several components working together, such as Customers, Production, Warehousing, and other concerns that need to be addressed. Therefore, the goal is to break things down into smaller parts and handle them as independently as possible. However, not all these parts (or subdomains) are equally important; for the critical ones (the Core), it is necessary to invest more

📄 Page 9

What is Domain-Driven Design? 4 time and effort to understand them properly. The others are just details, and we might not need to implement them. In this case, it may be enough to find a solution that already exists on the market (such as Payments or Accounting) that can address a less critical issue for the core of the business or system. The Core, the central part of the business, sets the company apart from the competition. Without it, the company risks being pushed out of the market. Let’s take a step back and look at things from the developer’s point of view. Usually, the team includes a business analyst or, in an agile project, a product owner who acts as a link between the business and the development team. Typically, all communication goes through the business analyst or product owner. However, this isn’t always the best way because of the gaps between the business and development worlds. Communication is the most important part of Domain-Driven Design—something people need to fully understand. It calls for closer collaboration between domain experts, who know the company’s operations, and the development team. Businesses tend to talk in their own terms, such as accounts, debiting, and crediting, while developers often interpret these concepts differently. That’s why establishing a shared understanding and, ultimately, a common language for communication is crucial. To conclude, Domain-Driven Design’s key objectives are: • Centering the project’s focus on the business domain and its logic. • Employing a domain model to facilitate the creation of complex designs • Establishing a collaborative effort between technical and domain experts to refine a conceptual model that addresses specific domain problems iteratively. https://www.professional-programmer.com

📄 Page 10

Why do we need Domain‐Driven Design? The primary advantages: • Eases Communication - It helps teams develop a shared model. The business and developer teams can then use this model to communicate business requirements, data entities, and process models. • Provides Flexibility - This implies that almost everything in the domain model is built around objects and will be modular and encapsulated, allowing the system to be continually updated and improved. Domain- Driven Design offers flexibility because it promotes the Separation of Concerns (SoC) and the isolation of different parts of the domain that represent business knowledge. After several rounds of discussions and idea exchanges, the different teams working on the business domain model will eventually develop a more suitable model for implementation that aligns with customer expectations. • Improved Patterns — It provides software developers with principles and patterns to solve difficult problems in software and sometimes in business. It’s also crucial to understand that an approach based on Domain-Driven Design can help align business and development. This means that the model created by developers will represent the business domain and may influence the business and its internal behavior. As developers or technical experts, we’ll start by analyzing and modeling the business domain. Because the business teammay not have a clear picture of all the details up front, the feedback they receive from the technical team will help them improve their understanding of how the business works and, possibly, identify any gaps or difficult-to-solve impediments. • Reduced Risk of Misunderstandings — Requirements are always ex- plained from a domain perspective. Conceptualizing the software system in terms of the business domain reduces the risk of misunderstandings between domain experts and the development team. Effective commu- nication and a common language will, of course, help reduce the risk of misunderstandings. Although effective communication between business

📄 Page 11

Why do we need Domain-Driven Design? 6 and development teams may be challenging at first, working together and developing a common language will gradually reduce the number of misunderstandings or issues caused by different perspectives. As a result, the number of iterations needed to gather requirements or understand the details of the problem we’re trying to solve as technical experts will decrease over time. Nothing is 100% suitable for every single use case, and, of course, there are also some disadvantages: • Additional Effort Required - The main drawback of adopting Domain- Driven Design in software development is the extra effort and time needed to build a detailed business domain model before seeing positive effects on the development process. Domain-Driven Design is a method- ology that works especially well for complex systems or solutions. For instance, if we develop a To-Do app or a small website for a client, it usually doesn’t make sense to invest in Domain-Driven Design because it takes a lot of time to understand and model the business. However, even in simple applications, we can often use Domain-Driven Design building blocks and patterns to reap the benefits of cleaner code and a more organized architecture. • Requires Domain Experts - If not available “in-house”, they are often expensive to hire since they hold valuable knowledge. Domain experts are essential for a complex business, so we will need a team that can share knowledge and explain concepts to the technical team, which will use this knowledge to develop effective business models. However, this is challenging because domain experts are often busy and not always available, and coordinating everyone in the same room can be difficult. Keep this in mind when estimating the time needed to gather knowledge from various domain experts when creating or upgrading systems with complex business needs. • Suitable for Complex Applications - Domain-Driven Design aims to simplify complexity. It is an excellent software development approach, but it is not worth the effort for simple applications. • High Encapsulation can be an issue - A high level of isolation and encapsulation in a domain model may present a challenge for business domain experts. Hence, it’s essential to avoid technical details in the design phase. https://www.professional-programmer.com

📄 Page 12

Domain‐Driven Design Building Blocks The main Domain-Driven Design concepts (or building blocks) are [4]: • Domain - an area of knowledge (ontology), influence, or activity. The software domain is the subject area where the user applies a program. • Model - a system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain. • Ubiquitous Language - the language that the technical team will develop in collaboration with domain experts to share a common understanding of the problem that has to be solved. • Bounded Context - a concept that defines clear boundaries around a specific Model. Within these boundaries, the Ubiquitous Language remains consistent and unambiguous. Each Bounded Context represents a distinct area of the business Domain where a particular Model and its associated Ubiquitous Language apply without confusion. • Context Maps - a strategic design tool used to document the rela- tionships, dependencies, and communication patterns between Bounded Contexts, helping teams understand howdifferent parts of a system inter- act while maintaining their Ubiquitous Language within each boundary. There are only a few principles, but Domain-Driven Design is hard to understand because it involves a lot of storytelling, philosophy, and case studies of various real-world challenges to offer solutions. Domain [8] Domain-Driven Design revolves around the idea of solving an organization’s problems through code. This is achieved by focusing the investment of resources at the heart of the business logic of the application. The Domain refers to the world of the business we’re working with and the issues they’re trying to address. This usually involves integrating rules, processes, and existing systems into your solution. In other words, theDomain is the problem we need to solve.

📄 Page 13

Domain-Driven Design Building Blocks 8 In most businesses, certain terms have specific meanings. They will prob- ably include metrics, goals, and objectives tailored to their industry. The Domain of your project encompasses all your knowledge about the company and its operations. Model [8] The Model of a Domain-Driven Design project is the solution to a specific problem; it’s how we approach what the business is trying to solve by hiring us as technical experts and developers. So, after several discussions, defining the common language (or Ubiquitous Language, as it’s called in Domain-Driven Design), and gaining enough knowl- edge about the specific Domain to meet the business needs, theModel is what we will produce. TheModel typically represents an aspect of reality or something of interest. Often, it also simplifies the bigger picture by focusing on the important parts of the solution and ignoring everything else. This means that theModel should concentrate on the knowledge related to a specific problem, which is simplified and organized to provide a solution. Ubiquitous Language To facilitate the fluent sharing of knowledge, Domain-Driven Design advocates for the cultivation of a shared, business-oriented language: the Ubiquitous Language. This language should resemble the business domain and its terms, entities, and processes — the abovementioned communication vehicle. Defin- ing a Ubiquitous Language is not trivial because the defined terms can have different meanings in different contexts. Another Domain-Driven Design concept is employed to overcome this hurdle: the Bounded Context. https://www.professional-programmer.com

📄 Page 14

Domain-Driven Design Building Blocks 9 Figure 1. Ubiquitous Language [5] For example, if the Accounting department needs a certain functionality implemented, everyone must share a common understanding of accounting concepts. Therefore, a balance sheet and other accounting terms should have the same meaning for both domain experts and technical staff. Similarly, the specific wording used in the Warehousing department must be clear. As programmers, in addition to knowing the vocabulary related to the specific knowledge area, we also need to understand what business rules, constraints, and validations we are expected to implement. Bounded Context / Context Maps The Bounded Context concept was introduced to isolate specific areas of the business from each other, all together constituting what is called aDomain. So, if we’re dealing with accounting, we’re going to have concepts like Customer, Product, and so on. Even though a Customer could be found in Orders or Sales, the details related to it in these contexts may differ from the details of the Customer in the Accounting context. In conclusion, there are some differences, https://www.professional-programmer.com

📄 Page 15

Domain-Driven Design Building Blocks 10 and it’s essential to isolate specific parts of the functionality, which is often referred to as, albeit somewhat cryptically, a Bounded Context. So, think of aBounded Context as an isolated sandbox that contains specific parts of the domain knowledge and does not interfere with other sandboxes. Within this sandbox, a language specific to that particular business area is defined — a specific Ubiquitous Language. Outside of this sandbox, the Ubiquitous Language’s termsmay have different meanings. ContextMaps are, basically, a way of describing how information can be exchanged between two sandboxes, such as Accounting and Sales, that both refer to a specificCustomer. For example, because the twodefinitions of the same concept are incompatible, we would not be able to access a Sales Customer with different attributes than an Accounting Customer. Context Maps serve to create some adapters on both sides while keeping the Customer concept unchanged on both sandboxes. Figure 2. Context Maps [5] An Upstream context influences the Downstream counterpart, but the reverse might not be true. This can apply to code (libraries depending on each other), as well as to less technical factors like schedules or responsiveness to external requests. We’ll almost certainly need some kind of safeguard for the downstream context to preserve its conceptual integrity against changes in the upstream one. DDD identifies several organizational patterns to describe and/ormanage interactions between different contexts. The best pattern for this is called “Anti-Corruption Layer” (ACL) [6], which requires an explicit translation be- tween the two contexts at the code level or, better yet, at the context’s external boundary [7]. https://www.professional-programmer.com

📄 Page 16

Domain‐Driven Design Patterns Now, let’s discuss the Domain-Driven Design Patterns in relation to the Build- ing Blocks. The most common ones are [4]: • Entity - an object defined by its identity rather than its attributes. Its state can change over time. Value Object - an object defined solely by its state and lacking any identity. These objects should be regarded as immutable. Aggregate - a collection of entities or value objects that are connected through an aggregate object. Aggregate Root - owns an Aggregate (it’s the main object) and serves as a gateway for all the changes within the Aggregate. Domain Event - an immutable domain object that defines an event (some- thing that has already happened) about which other domain parts could be interested in reacting. Domain Service - when an operation does not conceptually belong to any object, it can be implemented as a service. Repository - themethods for retrieving domain objects should be delegated to a dedicated Repository object. Factory - the methods for creating domain objects should be delegated to a specialized Factory object so that alternative implementations can be easily swapped. The diagram below provides an overview of the key domain-driven design concepts:

📄 Page 17

Domain-Driven Design Patterns 12 Figure 3. Domain-Driven Design landscape [9] https://www.professional-programmer.com

📄 Page 18

The E‐Commerce Domain‐Driven Design Sample Introduction In this chapter, I’ll provide a high-level overview of the concepts behind a sample e-commerce solution. Before applying Domain-Driven Design, the Domain of such a system might look like this UML Package diagram [10, 11]: Figure 4. High-Level E-Commerce sample Domain [11] Let’s start applying Domain-Driven Design to this sample Domain: 1. Identify the possible sub-domains within a Domain (the “problem” to solve). A Domain has its own strategic challenges, which can be seen as sub-domains classified as Core, Support, and Generic. 2. Divide the Domain into sub-domains. It’s a good practice to establish a Bounded Context for each one. The result [11]:

📄 Page 19

The E-Commerce Domain-Driven Design Sample 14 Figure 5. High-Level E-Commerce sample Domain [11] - After DDD In the previous UML Package diagram, the identified Bounded Contexts are categorized (using stereotypes) as Core, Support, and Generic. Typically, there is only one Core, which represents the main part of the Domain — the Product Catalog. The Support Bounded Contexts are auxiliary. They will support the Core but will have their own model. Generic Bounded Contexts are similar to Support ones, but they have a key difference: they are quite generic so that they can be used not only within the domain where they were created but also by other domains. Requirements and Modelling [12] • Identify User Stories - identify the user stories (the backlog grooming) following the role-feature-benefit pattern (or template) [13]: As a [type of user], I want [an action], so that [a benefit/value] • Identify theNouns in the user stories -> Entities - the nounswill become the main objects, not attributes. Just to enumerate a few of them in the context of the E-Commerce sample: Customer, Item,Order, ShoppingCart • Identify the Verbs in the user stories -> Behavior - in the same context, these can be Add items to the Shopping Cart, Specify delivery address, and many others • Identify object interaction (UML diagram) [14] https://www.professional-programmer.com

📄 Page 20

The E-Commerce Domain-Driven Design Sample 15 Figure 6. The object interaction diagram • Identify object responsibilities (UML diagram) [14] https://www.professional-programmer.com