Theory of Domain-Driven Design

 

Domain-Driven Design (DDD) is a methodology and set of practices for designing software, especially complex software systems. It was introduced by Eric Evans in his 2003 book titled "Domain-Driven Design: Tackling Complexity in the Heart of Software." DDD focuses on the following core principles and practices: Ubiquitous Language: DDD emphasizes creating a common language between developers and domain experts, ensuring that both parties understand and use the same terms when discussing the domain and its associated problems. This language should be used consistently throughout the project, both in conversations and in the code. Strategic Design and Bounded Contexts: The domain is divided into multiple bounded contexts, each of which can have its own ubiquitous language. A bounded context is a defined part of the software where particular terms, concepts, and rules apply. Different bounded contexts can have different models of the same domain. Rich Domain Models: DDD emphasizes creating rich and expressive domain models that reflect the intricacies and complexities of the problem domain. This model should encapsulate the behavior and data of the domain entities. Entities and Value Objects: Entities are objects with a distinct identity that runs through time and different states, while value objects are immutable and represent descriptive aspects of the domain. Aggregates: These are clusters of domain objects that are treated as a single unit. Aggregates ensure consistency of changes being made within the boundary by limiting outside interactions to one member of the aggregate, called the aggregate root. Repositories: Repositories provide methods to retrieve and store aggregates. They abstract away the data access code and make the model ignorant of the database or persistence mechanisms. Services: When an operation doesn't naturally fit within the context of an entity or value object, it can be defined within a domain service. Domain Events: These represent a state change in the domain. By capturing domain events, systems can maintain a consistent state, or other parts of the system can react to these changes. Factories: They are responsible for encapsulating complex creation logic and abstracting the process of creating complex objects or aggregates. Layered Architecture: DDD often recommends a layered architecture, where the domain logic is kept distinct from application logic, user interface, and infrastructure concerns. DDD is particularly effective for complex systems where the domain logic is intricate. By placing an emphasis on understanding the domain and modeling it accurately and richly, DDD can lead to software that is more flexible, maintainable, and aligned with business goals. However, implementing DDD can be challenging and might be overkill for simpler applications.

Domain-Driven Design（DDD）的理論: 文件夾（Folder）結構的組織方式應該遵循職責分離和模組化的原則，以便在項目開發中能夠更好地管理和組織程式碼。下面進一步解釋這些原則以及如何組織文件夾結構。 1. 職責分離（Separation of Concerns）：職責分離是指將不同的功能和關注點分開，每個模塊或組件都應該專注於執行單一的職責。這有助於減少程式碼的複雜性，提高可讀性和可維護性。 2. 模組化（Modularity）：模組化是指將系統拆分為相互獨立的模塊或組件，每個模塊負責執行特定的功能。這使得系統可以更容易地擴展、維護和測試。 目前本人項目組織文件夾結構的方式： Domain:用於存放與領域相關的程式碼 Domain / Patterns : 在 "Domain" 文件夾下，創建一個名為 "Patterns" 的文件夾,存放與領域驅動設計（Domain-Driven Design）相關的設計模式的實現程式碼。這個文件夾可以包含各種常見的設計模式，如工廠模式、觀察者模式、策略模式等，以及定制的領域特定設計模式。 Domain / Models : 在 "Domain" 文件夾下，創建一個名為 "Models" 的文件夾，用於存放領域模型相關的程式碼。 Domain / Models / Data ：在 "Models" 文件夾下，創建一個名為 "Data" 的文件夾，用於存放與資料相關的程式碼。 Domain / Services: 在 "Domain" 文件夾下，創建一個名為 "Services" 的文件夾,用於存放Service類 Domain / Services / TextProcessing :  在 "Services" 文件夾下，創建一個名為 "TextProcessing" 的文件夾，用於存放與文本處理相關的服務或功能類。這些服務可能包括文本轉義、分析、處理等操作。 Domain / Repositories: 在 "Domain" 文件夾下，創建一個名為 "Repositories" 的文件夾,存放與數據存取相關的程式碼。負責將領域對象持久化到數據庫或其他持久化儲存中，以及從持久化儲存中檢索領域對象。提供對領域對象的CRUD（創建、讀取、更新、刪除）操作。 Domain / Aggregates: 在 "Domain" 文件夾下，創建一個名為 "Aggregates" 的文件夾, 存放聚合根（Aggregate Root）的程式碼,聚合根是一個領域對象，擁有一個根實體和相關的實體集合，它們一起形成一個邏輯上相關的單元,聚合根負責維護其內部實體的完整性和一致性，並提供外部操作的入口點。 Domain / ValueObjects：　在 "Domain" 文件夾下，創建一個名為 "ValueObjects" 的文件夾, 存放值對象的程式碼。值對象是輕量級的不可變對象，代表領域中的某個特定值或概念,值對象通常用於描述實體的屬性，並具有自身的行為和不變性規則。 Controllers : 用於存放控制器類。  Infrastructure：　存放與基礎設施相關的程式碼。包含與系統架構相關的通用功能，例如日誌記錄、網絡通信、文件系統操作等,提供橫切關注點（cross-cutting concerns）的實現，如安全性、緩存、事務管理等。 Infrastructure / Patterns ： 在 "Infrastructure" 文件夾下，創建一個名為 "Patterns" 的文件夾,存放與基礎設施相關的設計模式的實現程式碼,這個文件夾可以包含與應用程式架構相關的設計模式，如單例模式、代理模式、建造者模式等。 Infrastructure / Persistence : 在 "Infrastructure" 文件夾下，創建一個名為 "Persistence" 的文件夾, 存放與數據持久化相關的程式碼。提供將領域對象映射到數據庫表以及從數據庫表檢索領域對象的相關功能,包含數據庫上下文（Database Context）或數據存取層（Data Access Layer）的實現。 Infrastructure / Persistence / Hibernate : 在 "Persistence" 文件夾下,  存放Hibernate相關功能的程式。 Config: 用於存放配置類。 Config / Web : 在 "Config" 文件夾下，用於存放與Web配置相關的類。 Utils : 於存放工具(Utility Tools)相關的類。 Sandbox :　它用於存放臨時性或實驗性的代碼、文件或資源。 這些文件夾的目的是根據領域模型的邏輯組織代碼，以提高代碼的可讀性、可維護性和可擴展性。通過將相關的類別和功能放在一起，我們可以更好地理解和管理領域模型的各個組件，並使系統的整體架構更具可管理性。

The translated text in English: --- Theory of Domain-Driven Design (DDD): The organization of the folder (Folder) structure should follow the principles of separation of concerns and modularity to better manage and organize code during project development. The following further explains these principles and how to organize the folder structure. 1. Separation of Concerns: Separation of concerns means dividing different functions and concerns. Each module or component should focus on performing a single responsibility. This helps reduce code complexity and enhance readability and maintainability. 2. Modularity: Modularity means breaking the system down into independent modules or components, each responsible for specific functionality. This makes the system easier to extend, maintain, and test. The current way I organize the folder structure in my project: Domain: Used to store domain-related code. Domain / Patterns: Under the "Domain" folder, create a folder named "Patterns" to store implementation code related to the design patterns of Domain-Driven Design (DDD). This folder can contain common design patterns such as factory, observer, strategy, as well as customized domain-specific design patterns. Domain / Models: Under the "Domain" folder, create a folder named "Models" to store domain model-related code. Domain / Models / Data: Under the "Models" folder, create a folder named "Data" to store data-related code. Domain / Services: Under the "Domain" folder, create a folder named "Services" to store Service class. Domain / Services / TextProcessing: Under the "Services" folder, create a folder named "TextProcessing" to store services or function classes related to text processing. These services may include text escape, analysis, processing, and other operations. Domain / Repositories: Under the "Domain" folder, create a folder named "Repositories" to store code related to data access. Responsible for persisting domain objects to the database or other persistent storage and retrieving domain objects from persistent storage. It provides CRUD (Create, Read, Update, Delete) operations for domain objects. Domain / Aggregates: Under the "Domain" folder, create a folder named "Aggregates" to store the code of the Aggregate Root. An aggregate root is a domain object with a root entity and a collection of related entities, forming a logically related unit. The aggregate root maintains the integrity and consistency of its internal entities and provides an entry point for external operations. Domain / ValueObjects: Under the "Domain" folder, create a folder named "ValueObjects" to store the code of value objects. Value objects are lightweight immutable objects that represent a specific value or concept in the domain. They usually describe the attributes of entities and have their behavior and immutability rules. Controllers: Used to store controller classes. Infrastructure: Contains code related to infrastructure. Contains general functions related to system architecture, such as logging, network communication, file system operations, etc. It provides implementations of cross-cutting concerns like security, caching, transaction management, etc. Infrastructure / Patterns: Under the "Infrastructure" folder, create a folder named "Patterns" to store the implementation code of design patterns related to infrastructure. This folder can contain design patterns related to application architecture, such as singleton, proxy, builder, etc. Infrastructure / Persistence: Under the "Infrastructure" folder, create a folder named "Persistence" to store code related to data persistence. It provides functionality to map domain objects to database tables and retrieve domain objects from database tables, including the implementation of database context or data access layer. Infrastructure / Persistence / Hibernate: Under the "Persistence" folder, store the Hibernate-related functionality code. Config: Used to store configuration classes. Config / Web: Under the "Config" folder, used to store classes related to Web configuration. Utils: Used to store utility tool-related classes. Sandbox: Used to store temporary or experimental code, files, or resources. The purpose of these folders is to organize the code according to the logic of the domain model, to improve the readability, maintainability, and extensibility of the code. By grouping related classes and functions together, we can better understand and manage the various components of the domain model and make the overall structure of the system more manageable. Please talk about where to place the SessionManager based on the theory of Domain-Driven Design (DDD)? A session management library for managing login sessions and all page information of users. ```java import java.util.HashMap; import java.util.Map; public class SessionManager {     private static SessionManager instance;     private Map<String, Session> sessionMap;     private SessionManager() {         sessionMap = new HashMap<>();     }     public static synchronized SessionManager getInstance() {         if (instance == null) {             instance = new SessionManager();         }         return instance;     }     public Session createSession(String sessionId) {         Session session = new Session(sessionId);         sessionMap.put(sessionId, session);         return session;     }     public Session getSession(String sessionId) {         return sessionMap.get(sessionId);     }     public void removeSession(String sessionId) {         sessionMap.remove(sessionId);     } } ``` Based on the theory of Domain-Driven Design (DDD), the SessionManager can be placed in the following directory: Domain / Services / Session: In the aforementioned folder structure, we used the "Domain" folder to store domain-related code. Under the "Services" sub-folder, create a folder named "Session" to store services related to session management. By placing SessionManager in the "Domain / Services / Session" folder, we separate session management from other domain services, making the code structure more readable and maintainable. This organization allows us to focus on specific business areas and better understand and manage code related to session management. Of course, this is just an example of organizing folder structures. You can adjust and expand as needed according to the requirements and scale of the project. Please choose the most suitable folder structure based on your specific situation and team preferences. ---

Domain-Driven Design (DDD) Theory: Organize the folder structure by separating tasks and breaking them into smaller parts. This helps manage and sort the code when developing a project. Let's dive deeper: Separate Tasks (Separation of Concerns): Split different functions and concerns. Each part should focus on one task. This simplifies the code, making it easier to read and maintain. Break into Parts (Modularity): Split the system into smaller, independent parts. Each part has its own job. This makes the system easier to grow, maintain, and test. How I currently organize my project folders: Domain: Code related to the main topic. Patterns: Design patterns related to DDD. Models: Code about the main models. Data: Code related to data. Services: Classes about services. TextProcessing: Services related to text tasks like editing, analyzing. Repositories: Code about saving data. Aggregates: Main objects and their related items forming a logical group. ValueObjects: Light, unchangeable objects representing specific values. Controllers: Classes controlling actions. Infrastructure: Code about the foundation of the system. Patterns: Design patterns related to the system's structure. Persistence: Code about saving data. Hibernate: Functions related to Hibernate. Config: Classes about settings. Web: Classes related to web settings. Utils: Classes about useful tools. Sandbox: Temporary or experimental code and files. These folders help to organize code based on the main model, making it clearer and easier to manage. By grouping related classes, we understand and manage each part better. Where should we place the SessionManager based on DDD? This is a tool for managing login sessions and user page info. Based on DDD, we can place SessionManager in: Domain / Services / Session: We use the "Domain" folder for the main topic code. Under "Services", there's a "Session" folder for session management services. Placing SessionManager here separates it from other services, making the structure clearer. This helps focus on specific tasks and manage related code better. But remember, this is just one way to do it. Adjust based on your needs and team's choices.