DDD (Domain-Driven Design) differs from traditional OOA/D (Object-Oriented Analysis and Design) in the following points:
Domain-driven design focuses on establishing a common language, enabling business experts and technical personnel to communicate and collaborate, and to solve business problems more efficiently. The traditional OOA/D puts more emphasis on the construction of analysis model and design model.
DDD pays more attention to the abstraction of the domain model, and splits and combines the elements in the domain to form a complete model under each sub-domain, helping developers maintain consistency in the implementation process. On the other hand, OOA/D focuses more on abstracting objects and classes, and completes system construction through combination and inheritance.
DDD pays more attention to the evolution of the domain model, regards it as something that cannot be static, and continuously optimizes and improves it as business requirements change. While OOA/D pays more attention to the scalability of the system and the reusability of the code.
DDD pays more attention to the discovery of business characteristics, and expresses various constraints and rules in the domain model, thus providing a basis for later development work. OOA/D pays more attention to object-oriented programming ideas, emphasizing concepts such as encapsulation, inheritance and polymorphism.
In general, DDD focuses on the business domain itself, as well as the problems and requirements found in this domain, while OOD pays more attention to the software system itself. DDD solves problems through domain modeling and the establishment of a common language, while OOD pays more attention to the optimization of system performance and architecture.
What is the difference between the process of analyzing business through DDD and the process of OOA/D?
Divide the domain model
DDD emphasizes abstracting and modeling the business domain, divides complex business logic into multiple sub-domains (Sub-Domain), and then designs a corresponding domain model for each sub-domain. The traditional OOA/D pays more attention to the analysis and design of the whole system.
define a common language
In DDD, defining a common language (Ubiquitous Language) is a very important step. During this process, developers must actively communicate with business experts and correspond the business terms and rules they understand with code implementation. The traditional OOD pays more attention to the modeling of objects, classes, data and so on.
Implement the domain model
In DDD, the domain model is the core, and programmers need to convert the domain model into code implementation to ensure the consistency of the code and the domain model. In traditional OOD, programmers need to implement corresponding programming according to the analysis model.
Drive code implementation in the domain
In DDD, the domain model is the dominant direction of code implementation, and programmers and business experts share the domain model, which can effectively avoid the problem of unclear requirements caused by the language barrier between business experts and programmers. In traditional OOA/D, analysis model and design model are the dominant direction.
In short, DDD focuses on the business domain itself, emphasizing the establishment of domain modeling and common language starting from the actual business, and keeping the domain model and code implementation consistent; while the traditional OOA/D focuses more on the system architecture and data. Organizational and other technical considerations.
at last
From the perspective of personal actual application scenarios, in fact, there is a great learning cost from traditional object-oriented to DDD, and for DDD, a certain depth and abstraction of business understanding are required. For example, the writing and usage of spring's mvc three-layer transfer to DDD may have 101 understanding and splitting methods in 100 companies, and DDD has many new concepts. Of course, it does not mean that DDD is not good. It depends on the actual scene, such as using Boundary is a very good tool for DDD to split and analyze business. Of course, everything still needs to proceed from reality~ There is no good or bad, only suitable or not~