Masaryk University Faculty of Informatics Domain-driven design with architectural patterns Master’s Thesis Marek Turis Brno, Spring 2019 Replace this page with a copy of the official signed thesis assignment anda copy of the Statement of an Author. Declaration Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Marek Turis Advisor: RNDr. Jaroslav Bayer i Acknowledgements I would like to thank my supervisor, RNDr. Jaroslav Bayer, for his guidance and valuable advice while writing this thesis. I would also like to thank my family and friends for the patience and the support when I did not have as much time for them as I wished. ii Abstract This thesis focuses on Domain-driven design, an approach to software development, and architectural patterns and styles. With an analysis of the patterns in the context of Domain-driven design, the compatibility and possibility of the combination of a given pattern and Domain- driven design are examined. An exemplary system is presented that is built on the principles of Domain-driven design and uses the described architectural patterns and styles. iii Keywords Domain-driven design, software architecture, architectural patterns, architectural styles, domain, bounded context iv Contents 1 Introduction 1 2 Principles of Domain-driven design 3 2.1 Domains ............................3 2.2 Knowledge crunching .....................4 2.3 Domain model .........................5 2.4 Bounded context .......................6 2.5 Context maps .........................7 3 Tactical patterns 10 3.1 Entities ............................ 10 3.2 Value objects ......................... 10 3.3 Domain services ........................ 11 3.4 Aggregates .......................... 11 3.5 Domain events ........................ 11 3.6 Modules ............................ 12 3.7 Factories ............................ 12 3.8 Repositories .......................... 12 4 Architecture 14 4.1 Patterns of domain logic ................... 14 4.1.1 Transaction script . 15 4.1.2 Table module . 16 4.1.3 Anemic domain model . 17 4.2 Architecture of bounded contexts ............... 17 4.2.1 Big ball of mud . 17 4.2.2 Layered Architecture . 19 4.2.3 Hexagonal architecture . 21 4.2.4 IDesign . 22 4.2.5 Command query responsibility segregation . 25 4.2.6 Event sourcing . 28 4.2.7 Pipes and filters . 31 4.3 Top-level architecture ..................... 35 4.3.1 Monolithic architecture . 35 4.3.2 Service-oriented architecture (SOA) . 41 4.4 Integration of bounded contexts ............... 43 v 4.4.1 File transfer . 45 4.4.2 Shared database . 45 4.4.3 Remote procedure invocation . 46 4.4.4 Messaging . 46 5 Designing Domain-driven design system 48 5.1 Requirements ......................... 48 5.2 Analysis ............................ 49 5.3 Top-level architecture ..................... 51 5.4 Architecture of bounded contexts ............... 53 6 Conclusion 57 6.1 Future work .......................... 57 Bibliography 58 vi List of Figures 4.1 Big ball of mud with Domain-driven design 18 4.2 Layered architecture 20 4.3 Layers used on a bounded context level 21 4.4 Hexagonal architecture of one bounded context 23 4.5 IDesign components overview 24 4.6 IDesign method used with DDD on a bounded context level 26 4.7 CQRS applied to the whole system 27 4.8 CQRS using DDD 29 4.9 Event sourcing used together with CQRS and DDD 32 4.10 Pipes and filters inside a bounded context 34 4.11 Monolithic architecture 36 4.12 Layers used on a system level 38 4.13 IDesign – bounded context mismatch 40 4.14 Bounded contexts with different architectures 44 5.1 Bounded contexts and subdomains of UniSys2. 52 5.2 Overview of top-level services. 53 vii 1 Introduction As information technologies were gaining popularity in the second half of the 20th century, requirements on information systems grew rapidly. Small applications evolved into complicated systems with rich features, adapting to the increasing demands of customers. As the size of a system grows, so does its complexity, which can make the system harder to understand, maintain, and evolve. New projects did not have it any easier. Large projects were a particular challenge for architects who needed to design systems that would accommodate the requirements of customers, prove useful in practice, and solve the problems the software was intended to tackle. Failing to correctly grasp the requirements of a customer resulted in a system that was not useful and did not deliver the solution to the problems that mattered most. In 2003, Eric Evans published his book, Domain-Driven Design: Tackling Complexity in the Heart of Software [1] that tries to tackle the challenges of designing large systems. In the book he introduced Domain-driven design (DDD), an approach to software design, with its focus on a modeled domain and collaboration between domain experts and developers throughout the entire software development process. The main contribution of Evans’ work lays in introducing practices, principles and patterns that help in all steps of designing software, from requirements engineering to designing implementation solutions. Since the publication of Evans’ book, DDD was examined and described in many derivative books and articles. These publications focused either on the business side of DDD or its usage at the lower level of the system. Particularly popular are the design (tactical) pat- terns that Evans presented. However, a broader work that would focus on DDD in high-level design and its usage in combination with differ- ent architectural patterns is missing. This thesis focuses on presenting various architecture patterns and examines their compatibility and usage with DDD. The structure of the thesis is as follows. The first part introduces DDD with its principles and patterns. Next chapters focus on architec- ture patterns and styles. Given patterns are always briefly described 1 1. Introduction and, as the main goal of this thesis, their usage with DDD is analyzed, mainly their compatibility with the goals of DDD and the possibil- ity of using them in DDD systems. The most important patterns are demonstrated in practice on an exemplary system. 2 2 Principles of Domain-driven design Domain-driven design is a development philosophy that was defined by Eric Evans in his book Domain-Driven Design: Tackling Complexity in the Heart of Software. It is an approach that emphasizes the importance of a domain, its proper understanding and collaboration of domain experts with developers. It also presents patterns that can be used together with gained knowledge to design the best possible solution. The main areas where DDD can help are: ∙ knowledge crunching, ∙ collaboration of domain experts with developers, ∙ system design, ∙ refactoring. 2.1 Domains A Domain is basically what an organization does and the environment it does it in [2]. It is an area in which the company operates, and the software is intended to solve problems in this area. A domain can be decomposed into smaller parts, subdomains. Domain-driven design differentiates three types of subdomains: ∙ core domain, ∙ supporting domain, ∙ generic domain. Core domain A core domain is the most important part; it is the heart of the business. It is what makes money and what is the business most focused on and it has the primary importance to the success of the organization [2]. For example for e-shops, the core domain is selling of goods. The core domain is a subdomain where DDD should be applied the most. 3 2. Principles of Domain-driven design It is essential that it gets the most attention and that it is modeled, designed and developed as good as possible. This should be achieved by the increased involvement of domain experts and participation of the best developers in the team [3]. Supporting domain Supporting domains are domains that are not the main focus of the organization, but they help to support core domains. For example for e-shops, warehouse management is not a core domain, it is not what makes money, it only helps to support the core domain of selling goods. Generic domain A generic domain is the least important domain for an organization. It is a subdomain that many systems have, such as sending newsletters. Generic domain doesn’t require much attention and in an ideal case an existing product can be used to save time which can be rather invested in the core domain. 2.2 Knowledge crunching Domain-driven design puts the domain at the center of every stage of software development. To design a useful system, developers need to understand the domain, the processes that happen in given situa- tions, what is important and how it is achieved. People who provide knowledge about the domain are called domain experts. Domain experts and developers should frequently interact and during the whole development process. Even though this interaction can be time-consuming for both, domain experts and developers, it will pay off in the long run. The ideal situation is when domain expert can be a permanent part of a developer team. The important part is direct and ongoing interaction between domain experts and devel- opers, knowledge crunching based on traditional waterfall software 4 2. Principles of Domain-driven design development model1, in which domain analyst will in requirements engineering stage get knowledge from experts and then pass it to developers, will most likely not lead to best results. This is because developers are limited to the knowledge which domain analyst gained and which he found useful. Furthermore, if they need further informa- tion or explanation, they either cannot get it from an expert, because "that was done in the first stage", or they can only do it very infre- quently to "not bother domain experts too much".