Differences

This shows you the differences between two versions of the page.

--- arch:strategic_domain_driven_design_and_enterprise_architecture [2021/10/17 18:29] – vekugay
+++ arch:strategic_domain_driven_design_and_enterprise_architecture [2026/08/29 07:59] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
-=====Strategic domain driven design and enterprise architecture=====
+===== Strategic domain driven design and enterprise architecture =====
 By Victor Kugay (vekugay@edu.hse.ru)
-=====Introduction=====
+===== Introduction =====
-Domain-Driven (DDD) design is not a technology or a methodology. It is a way of thinking and a set of priorities which help us to speed up software projects that have to deal with complicated domains. The DDD patterns such as Entity, Value Object, Aggregate and Repository have been used in software engineering to model complex business domains since Domain-driven Design has been introduced by Eric Evans in 2003((Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley)). Generally, DDD can be divided into three areas. First one is basic building blocks. It describes how to isolate the domain from technology by use of a layered architecture and combined with practical object-oriented design patterns. The next one is sophisticated models. This block aligns software with domain expert thinking, domain concepts are made explicit in code and refactoring of the code is driven by domain insight. The final is strategic design – addresses model consistency and management of complexity in larger systems.
+Domain-Driven (DDD) design is not a technology or a methodology. It is a way of thinking and a set of priorities which help us to speed up software projects that have to deal with complicated domains. The DDD patterns such as Entity, Value Object, Aggregate and Repository have been used in software engineering to model complex business domains since Domain-driven Design has been introduced by Eric Evans in 2003[[arch:strategic_domain_driven_design_and_enterprise_architecture|1)]]. Generally, DDD can be divided into three areas. First one is basic building blocks. It describes how to isolate the domain from technology by use of a layered architecture and combined with practical object-oriented design patterns. The next one is sophisticated models. This block aligns software with domain expert thinking, domain concepts are made explicit in code and refactoring of the code is driven by domain insight. The final is strategic design – addresses model consistency and management of complexity in larger systems.
 Strategic Domain-driven Design can be used to decompose the problem domain of a software system into multiple sub-domains and the so-called Bounded Contexts. It also allows architects to define the relationships between Bounded Contexts, e.g., how they work together. Strategic design provides three main building blocks: Context mapping, Distillation, Large scale structure. During last few years strategic DDD was significantly gained especially in the context microservices and enterprise application integration.
-=====Problems and solutions=====
+===== Problems and solutions =====
-The decomposition of a monolithic application into multiple services is challenging. High cohesion within the services and loose coupling between them are one of the most preferable and crucial purposes to keep the application scalable and maintainable. Decomposing software systems into smaller, more maintainable and reliable units has been open research question for many years. Many scientists and developers already wrote about it. For instance, David Parnas wrote about decomposing systems into modules in 1972((Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Commun. ACM, 15(12):1053–1058)). Nevertheless, the strategic patterns have some ambiguity and different interpretations of how they should be used. It is not understood well yet how service interfaces can be decomposed and which practices and patterns are the most suitable and effective to design and analyze service-oriented systems. DDD can help us in answering many questions such as
+The decomposition of a monolithic application into multiple services is challenging. High cohesion within the services and loose coupling between them are one of the most preferable and crucial purposes to keep the application scalable and maintainable. Decomposing software systems into smaller, more maintainable and reliable units has been open research question for many years. Many scientists and developers already wrote about it. For instance, David Parnas wrote about decomposing systems into modules in 1972[[arch:strategic_domain_driven_design_and_enterprise_architecture|2)]]. Nevertheless, the strategic patterns have some ambiguity and different interpretations of how they should be used. It is not understood well yet how service interfaces can be decomposed and which practices and patterns are the most suitable and effective to design and analyze service-oriented systems. DDD can help us in answering many questions such as
->which criteria are relevant to find adequate services boundaries and which patterns and practices can be applied to identify candidate services((Pautasso, C., Zimmermann, O., Amundsen, M., Lewis, J., and Josuttis, N. (2017). Microservices in practice, part 1: Reality check and service design. IEEE Software, 34(1):91–98))?
-Developers who use microservices pattern suggest to leverage DDD patterns to answer the above design questions. DDD provide mechanisms to model software-intensive systems in terms of Bounded Contexts, and then implement one microservice for each Bounded Context. Microservices architecture has a lot of benefits but this is not a silver bullet and this approach also has disadvantages when essential benefits of this architecture became burdens: velocity plummeted, defect rate exploded((Experience from Failing with Microservices: https://segment.com/blog/goodbye-microservices)). Identification of suited Bounded Contexts is also challenging. Context Map can help us design models and diagrams. Context mapping as a practice and the strategic DDD patterns to define the relationships between Bounded Contexts also help us to be sure that Bounded Contexts are valid. Clear understanding of how these patterns shall work together is often missing. This is obvious that different stakeholders have different opinions on how these patterns should be applied and combined. To solve the issue software engineers can use Context Map to analyze and understand a domain.
+which criteria are relevant to find adequate services boundaries and which patterns and practices can be applied to identify candidate services[[arch:strategic_domain_driven_design_and_enterprise_architecture|3)]]?
-=====Example=====
+Developers who use microservices pattern suggest to leverage DDD patterns to answer the above design questions. DDD provide mechanisms to model software-intensive systems in terms of Bounded Contexts, and then implement one microservice for each Bounded Context. Microservices architecture has a lot of benefits but this is not a silver bullet and this approach also has disadvantages when essential benefits of this architecture became burdens: velocity plummeted, defect rate exploded[[arch:strategic_domain_driven_design_and_enterprise_architecture|4)]]. Identification of suited Bounded Contexts is also challenging. Context Map can help us design models and diagrams. Context mapping as a practice and the strategic DDD patterns to define the relationships between Bounded Contexts also help us to be sure that Bounded Contexts are valid. Clear understanding of how these patterns shall work together is often missing. This is obvious that different stakeholders have different opinions on how these patterns should be applied and combined. To solve the issue software engineers can use Context Map to analyze and understand a domain.
-In my team which develops different marketing projects with short lifetime within large bank ecosystem this is a crucial advantage of the Context Map and Bounded Contexts. Working with a lot of project and bank teams requires to design software with multiple dependencies. Practically, Context Map helps us to design communication between many bank domains i.e., services. Short timing doesn’t allow us to create multiple versions of the software and short project life doesn’t allow us to have multiple testing iterations during alpha or beta tests. Developers should spend as little time as possible to communicate with business, specify all requirements, design system, find and handle all corner cases or bottlenecks and retry design process if needed. Such circumstances require creating reach and clear diagrams which describes whole project architecture in order to many other teams which involved to the project know their responsibilities. Fortunately, DDD offers several relationship patterns allowing modelers to describe how two Bounded Contexts and the corresponding development teams work together. The Partnership relationship describes an intimate mutual relationship between two Bounded Contexts, since the resulting product of the two can only fail or succeed as a whole. A Shared Kernel relationship indicates that two contexts are very closely related and the two domain models overlap at many places. In my case bank infrastructure provide several core features which standardized and have shared library(([[https://www.youtube.com/watch?v=-KMWmXTr2LE|Как мы в Tinkoff принимаем архитектурные решения]])).
+===== Example =====
+In my team which develops different marketing projects with short lifetime within large bank ecosystem this is a crucial advantage of the Context Map and Bounded Contexts. Working with a lot of project and bank teams requires to design software with multiple dependencies. Practically, Context Map helps us to design communication between many bank domains i.e., services. Short timing doesn’t allow us to create multiple versions of the software and short project life doesn’t allow us to have multiple testing iterations during alpha or beta tests. Developers should spend as little time as possible to communicate with business, specify all requirements, design system, find and handle all corner cases or bottlenecks and retry design process if needed. Such circumstances require creating reach and clear diagrams which describes whole project architecture in order to many other teams which involved to the project know their responsibilities. Fortunately, DDD offers several relationship patterns allowing modelers to describe how two Bounded Contexts and the corresponding development teams work together. The Partnership relationship describes an intimate mutual relationship between two Bounded Contexts, since the resulting product of the two can only fail or succeed as a whole. A Shared Kernel relationship indicates that two contexts are very closely related and the two domain models overlap at many places. In my case bank infrastructure provide several core features which standardized and have shared library[[arch:strategic_domain_driven_design_and_enterprise_architecture|5)]].
 The experience from our use of strategic level Domain-Driven design is that context maps and the activity of context mapping can improve the quality of the Enterprise Architecture and its derived software architectures as well. Another finding is that being able to identify the projects core domain is important with respect to how to utilize development resources, and how developers choose to think about the software under development. The encountered challenge is for the business to agree on what is most important, where one of the discoveries is that in large scale systems there will be multiple cores. Next finding was that the combination of context maps and responsibility layers reduces the perceived complexity. In summary strategic level Domain-Driven design can be used to enhance Enterprise Architectures and the derived software architectures.
@@ Line 23: / Line 24: @@
 In larger projects enterprise architecture identifies the main components of the organization, its information systems and the ways in which these components work together in order to achieve defined business objectives. The components include staff, business processes, technology, information, financial and other resources required by the business to achieve its objectives enterprise architecture is based on a holistic view rather than an application-by-application view.
-=====Conclusion=====
+===== Conclusion =====
 DDD patterns can significantly accelerate developing process. Problems and solutions space aligned in a common language and an architecture that can incrementally accommodate change in order to move fast is the key to successful growth. That’s where strategic patterns play a role.
 Of course, DDD cannot solve all issues depend on software development but in particular cases Bounded contexts and Context Map also another DDD patterns can dramatically improve communication and responsibilities between developers and managers.
+[[arch:strategic_domain_driven_design_and_enterprise_architecture|1)]]
+Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley
+[[arch:strategic_domain_driven_design_and_enterprise_architecture|2)]]
+Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Commun. ACM, 15(12):1053–1058
+[[arch:strategic_domain_driven_design_and_enterprise_architecture|3)]]
+Pautasso, C., Zimmermann, O., Amundsen, M., Lewis, J., and Josuttis, N. (2017). Microservices in practice, part 1: Reality check and service design. IEEE Software, 34(1):91–98
+[[arch:strategic_domain_driven_design_and_enterprise_architecture|4)]]
+[[https://segment.com/blog/goodbye-microservices|Experience from Failing with Microservices]]
+[[arch:strategic_domain_driven_design_and_enterprise_architecture|5)]]
+[[https://www.youtube.com/watch?v=-KMWmXTr2LE|Как мы в Tinkoff принимаем архитектурные решения]]