From Jdon.com, DDD topic , click here to start
Eric Evans' "Domain-Driven Design Domain-Driven Design" is abbreviated as DDD. Evans DDD is a set of object-oriented modeling methods for comprehensive software system analysis and design .
In the past, system analysis and system design were separated, just like the two professional title examinations of "system analyst" and "system designer" in our country. The result of this separation leads to the result of requirement analysis that cannot be directly used for design and programming, but can be The code that is programmed and run distorts the requirements, so that after running the software, customers find that many functions are not what they want, and the software cannot quickly follow changes in requirements.
DDD breaks this gap, proposes the concept of domain model, unifies analysis and design programming, and makes software more flexible and fast to follow changes in demand. See the development efficiency comparison between DDD and traditional CRUD or procedural scripts or data table-oriented below:
There are three stages of server backend development:
- The two-tier architecture of UI+DataBase, this database-oriented architecture (table module above) has no flexibility.
- The multi-layer SOA architecture of UI+Service+DataBase, this service+table model architecture is easy to make the service become cystic, difficult to maintain and expand, and has poor scalability. See the discussion here or the biggest failure of Spring Web application .
- The event-driven CQRS read-write separation architecture of DDD+SOA can cope with complex business logic, replace the data table model with the aggregation model, and replace the serial message-driven with concurrent event-driven. Truly realize flexible expansion with business entities as the core.
The revolution of DDD lies in the fact that the domain model accurately reflects the business language, while traditional transactional programming models such as J2EE or Spring+Hibernate only care about data. These data objects do not have any business methods except simple setter/getter methods, which are likened to blood loss models. , so what's so good about the hyperemia model with business methods like the domain model?
Taking Match Match as an example, the competition has business behaviors such as "start" and "end", but the traditional and classic way is to put the "start" and "end" behaviors in the service service of the competition, rather than in the competition object itself. middle. We cannot use computers, databases, and frameworks, but the business model is kidnapped by the technical framework, just like although people are born by their mothers, their mothers cannot be replaced, let alone dismembered in the name of maternal love. A person's normal duty behavior, if this is the case, this person is kidnapped by mother's love.
Advocating the congestion model is actually to make the business model that was dismembered and hacked in the past return to normal. Of course, this will also be regarded as abnormal by some preconceived or brainwashed programmers, which is extremely sad. When you see the domain model code, you can see the business requirements. There is no translation and no conversion, so that the software can truly achieve "copy without distortion".
The biggest advantage of DDD is that the first step in contacting a requirement is to consider the domain model, rather than dividing it into data and behavior, then the data is implemented using the database, the behavior is implemented using the service, and finally the requirements are separated. DDD makes you think about business language first, not data. Different priorities lead to different programming worldviews.DDD is a set of effective ways to solve complex medium and large software, and it has become the mainstream in foreign countries. DDD believes that there are many reasons for the complexity of software. It is impossible for us to avoid these complexities. What we can do is to control complex problems. And a good domain model is the key to controlling complex problems. The value of the domain model is to provide a common language that enables domain experts and software technicians to connect and communicate without ambiguity.
The positioning of DDD in the software production process is as shown in the figure below. The implementation of DDD is inseparable from in-memory cache , CQRS, DCI , EDA or Event Source related fields.
DDD Fundamentals: Object-Oriented Topics
2012 Eric Evans session on how technology affects DDD
Aggregation with Consistency and Bounded Context
Tutorials and Articles
Comparison of two analysis and design methods, object-oriented modeling and database modeling.
Database-driven design and object modeling are the two major factions that determine the different fate of software. Who can make software more lifelike and more convenient to maintain and expand? More scalable?The natural impedance
software of object and relational databases is method-oriented. There are only two methods in this world: one is the method of simplifying complex problems; the other is the method of complicating simple problems. In the field of software, you can only choose the former.Object-Oriented and Domain Modeling
According to the survey, about 70% of programmers are currently using OO language to write traditional procedural software, and the lack of education and training in complete object-oriented thinking methods is the basic root cause. Questions offer independent insights and sharp points of viewHow Evans DDD domain modeling
refines the model instead of the data table, and then refines the model object so that it can reflect the basic nature of the domain concept. It is a complex process. Evans DDD is a revolutionary software idea proposed in 2004.Practical DDD (Evans DDD: Domain-Driven Design)
domain modeling is an artistic technique, not a mathematical technique. It is a solution to solve complex software and quickly cope with changes.Model Extraction of Domain Model Driven Design (Evans DDD)
状态对象：数据库的替代者
实体是一个有状态的对象，这是一个实战中非常重要但是容易被忽视的概念。如何从职 责和协作中发现丰富对象？
给出了DDD具体实践中一些具体细节，是和DDD配合一起进行面向对象分析设计的好方法。业务模型统一描述
统一语言是DDD一个重要特征和重点。DCI架构是什么？
DCI架构：DCI: 对象的Data数据, 对象使用的Context场景, 对象的Interaction交互行为Domain Events异步应用
领域驱动设计和异步架构完美实战解决之道。DDD DCI和领域事件
将DDD DCI Event sourcing结合在一个案例中，展示OOA和OOD实现过程，直至可运行的源代码。业务建模：CQRS应用场景
如何更好地在实践中实现DDD，又防止技术架构对业务领域的侵害，本文讨论引入CQRS使用场景。DSM：Domain-Specific Modeling
DSM是超越UML/MDA一种新的建模方法，它成倍提高软件开发效率。四色原型
我们在一个软件革命的开始，它象90年代我们看到的面向对象编程从传统过程语言中抽象出来一样。 如果说GOF设计模式开辟了OO对象设计新时代，那么原型模式和MDA将开辟后十年的软件新时代。更多四色专题Feature-Driven Development特征驱动开发
使用JdonFramework等现代Model/Service框架是在什么项目工程背景下进行的？不是以前的XP（Extreme Programming ）或RUP，而是FDD。UML和Java的阻抗
如果Java和UML这种发展概念不匹配下去，我们真的要问UML过时了吗？状态对象：数据库的替代者
这是一个实战中非常重要但是容易被忽视的概念，说它重要，是因为它比数据库重要；说它容易被忽视也是同样的原因，它经常被数据库概念替代。不变性immutablity设计
不变性是统领业务分析和高性能架构重要法门，通过业务上不变性分析设计，可以实现代码运行的并发高性能和高扩展性行为驱动开发(BDD)如何与领域驱动设计(DDD)结合？
BDD认为是在不断敏捷迭代开发中从用户故事中挖掘领域模型，这种敏捷开发方式是否与DDD矛盾呢？事件、契约设计与BDD
板桥banq提出中西结合的统一语言：场景 事件和状态，该文进行了论证。DDD CQRS和Event Sourcing的案例：足球比赛
DDD + CQRS + Event Sourcing实现案例，结合代码与理论讲解。集装箱车队系统的DDD案例
为上海某大型港口公司的运输系统实施的一个领域驱动设计DDD的实战咨询案例。