arch:industry_recognized_challenges_in_domain_driven_design_practice

Differences

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

Link to this comparison view

Next revision		 Previous revision
arch:industry_recognized_challenges_in_domain_driven_design_practice [2021/10/17 19:04] – created dvbutakovarch:industry_recognized_challenges_in_domain_driven_design_practice [2026/08/29 07:59] (current) – external edit 127.0.0.1
Line 1: Line 1:
-===== Industry recognized challenges in domain-driven design practice ====+===== Industry recognized challenges in domain-driven design practice ===== 
 By Dmitriy Butakov (dvbutakov@edu.hse.ru) By Dmitriy Butakov (dvbutakov@edu.hse.ru)
  
Line 9: Line 10:
  
 Before we understand what problems can arise when implementing DDD, let's briefly go over the terminology. First of all, the term “domain-driven design” should be defined and clarified. Domain-driven design is an approach to complex software which is [3]: Before we understand what problems can arise when implementing DDD, let's briefly go over the terminology. First of all, the term “domain-driven design” should be defined and clarified. Domain-driven design is an approach to complex software which is [3]:
 +
   - Focused on the core domain   - Focused on the core domain
   - Explores models with tied interaction between domain experts and software developers   - Explores models with tied interaction between domain experts and software developers
Line 14: Line 16:
  
 A domain represents a sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software [3]. To study a wide area of knowledge, an obvious solution is to split the subject area into smaller parts and determine the order of study. Likewise for solving large problem domains, the DDD approach requires determining Core Domain and Generic Subdomains. A domain represents a sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software [3]. To study a wide area of knowledge, an obvious solution is to split the subject area into smaller parts and determine the order of study. Likewise for solving large problem domains, the DDD approach requires determining Core Domain and Generic Subdomains.
 +
   * **Core Domain**. Defines the main set of features and responsibilities that require major efforts to be implemented. It should satisfy the proposed business model.   * **Core Domain**. Defines the main set of features and responsibilities that require major efforts to be implemented. It should satisfy the proposed business model.
   * **Generic Subdomains**.  Defines parts that include implementation details or other difficulties that make it harder to see the final goal or are not clear to experts, but are necessary for the implementation of the project.   * **Generic Subdomains**.  Defines parts that include implementation details or other difficulties that make it harder to see the final goal or are not clear to experts, but are necessary for the implementation of the project.
  
 After Core Doman and Generic Subdomains are distilled, the Domain Model creation process begins. Domain Model is a sample of distilled knowledge strictly organized by the pursued goals, which has a structure that is understandable for all participants in the process. It should be should directly map on architecture and source code. A model can consist of [3]: After Core Doman and Generic Subdomains are distilled, the Domain Model creation process begins. Domain Model is a sample of distilled knowledge strictly organized by the pursued goals, which has a structure that is understandable for all participants in the process. It should be should directly map on architecture and source code. A model can consist of [3]:
 +
   * **Entity** - a logically integral object with a set of individual traits that exist during the whole lifecycle   * **Entity** - a logically integral object with a set of individual traits that exist during the whole lifecycle
   * **Value object** - an object which describes some aspects of the domain and has no individual existence and self-identity   * **Value object** - an object which describes some aspects of the domain and has no individual existence and self-identity
Line 24: Line 28:
  
 The interaction between them is defined by associations. These objects should be maintained by their lifetime and associations. Maintenance is defined by several architecture templates [3]: The interaction between them is defined by associations. These objects should be maintained by their lifetime and associations. Maintenance is defined by several architecture templates [3]:
 +
   * **Aggregate** - a set of objects that are perceived as a whole in terms of data change, which has one root object and boundary. All external objects can refer only to the root object of aggregate, but objects within the boundary can refer in any way.   * **Aggregate** - a set of objects that are perceived as a whole in terms of data change, which has one root object and boundary. All external objects can refer only to the root object of aggregate, but objects within the boundary can refer in any way.
   * **Factory** - an abstraction that hides objects creation details (how it should be created, which data should be provided)   * **Factory** - an abstraction that hides objects creation details (how it should be created, which data should be provided)
Line 45: Line 50:
  
 ==== References ==== ==== References ====
-  - An introduction to Domain Drive Desing https://www.methodsandtools.com/archive/archive.php?id=97+ 
 +  - An introduction to Domain Drive Desing [[https://www.methodsandtools.com/archive/archive.php?id=97|https://www.methodsandtools.com/archive/archive.php?id=97]]
   - Eric Evans, “Domain-Driven Design: Tackling Complexity in the Heart of Software”, 2004   - Eric Evans, “Domain-Driven Design: Tackling Complexity in the Heart of Software”, 2004
   - Eric Evans, “Domain-Driven Design Reference: Definitions and Pattern Summaries”, 2015   - Eric Evans, “Domain-Driven Design Reference: Definitions and Pattern Summaries”, 2015
-  - Vaughn Vernon, “Implementing Domain-Driven Design”, Feb 6, 2013  +  - Vaughn Vernon, “Implementing Domain-Driven Design”, Feb 6, 2013 
-  - The Challenges of Applying DDD, https://www.informit.com/articles/article.aspx?p=1944876&seqNum=5 +  - The Challenges of Applying DDD, [[https://www.informit.com/articles/article.aspx?p=1944876&seqNum=5|https://www.informit.com/articles/article.aspx?p=1944876&seqNum=5]] 
-  - Ubiquitous Language и Bounded Context в DDD https://habr.com/ru/post/232881/ +  - Ubiquitous Language и Bounded Context в DDD [[https://habr.com/ru/post/232881/|https://habr.com/ru/post/232881/]] 
-  - Domain-Driven Design, My Top 5 Best Practices https://www.codeproject.com/Articles/1131462/Domain-Driven-Design-My-Top-Best-Practices +  - Domain-Driven Design, My Top 5 Best Practices [[https://www.codeproject.com/Articles/1131462/Domain-Driven-Design-My-Top-Best-Practices|https://www.codeproject.com/Articles/1131462/Domain-Driven-Design-My-Top-Best-Practices]] 
-  - Domain Driven Design на практике https://habr.com/ru/post/334126/ +  - Domain Driven Design на практике [[https://habr.com/ru/post/334126/|https://habr.com/ru/post/334126/]] 
-  - Domain, Subdomain, Bounded Context, Problem/Solution Space in DDD: Clearly Defined https://medium.com/nick-tune-tech-strategy-blog/domains-subdomain-problem-solution-space-in-ddd-clearly-defined-e0b49c7b586c +  - Domain, Subdomain, Bounded Context, Problem/Solution Space in DDD: Clearly Defined [[https://medium.com/nick-tune-tech-strategy-blog/domains-subdomain-problem-solution-space-in-ddd-clearly-defined-e0b49c7b586c|https://medium.com/nick-tune-tech-strategy-blog/domains-subdomain-problem-solution-space-in-ddd-clearly-defined-e0b49c7b586c]] 
-  - Uncovering Hidden Business Rules with DDD Aggregates https://medium.com/nick-tune-tech-strategy-blog/uncovering-hidden-business-rules-with-ddd-aggregates-67fb02abc4b +  - Uncovering Hidden Business Rules with DDD Aggregates [[https://medium.com/nick-tune-tech-strategy-blog/uncovering-hidden-business-rules-with-ddd-aggregates-67fb02abc4b|https://medium.com/nick-tune-tech-strategy-blog/uncovering-hidden-business-rules-with-ddd-aggregates-67fb02abc4b]] 
-  - Benefits of Domain Driven Design | And how to use it, https://medium.com/geekculture/benefits-of-domain-driven-design-and-how-to-use-it-58b9b1606c5a +  - Benefits of Domain Driven Design | And how to use it, [[https://medium.com/geekculture/benefits-of-domain-driven-design-and-how-to-use-it-58b9b1606c5a|https://medium.com/geekculture/benefits-of-domain-driven-design-and-how-to-use-it-58b9b1606c5a]]
- +
- +
  • arch/industry_recognized_challenges_in_domain_driven_design_practice.1634497459.txt.gz
  • Last modified: 2026/08/29 07:59
  • (external edit)