DDD 是个啥？

要是在技术社区活动中， 被问到DDD是干啥的话题， 很多人可以使用一句话， 这样回答：”DDD是一种聚焦于Domain的软件构建方式”。

事实上， 这句话没错！

不过，我们也可以说DDD是一种正确构建Domain Model的方式。

什么是Domain Model呢？  

如果我们查找“Model”一词定义的话，可以看到这样的说明“Mode是一个描述，采用了缩小规模（a reduced scale）的方式”。一旦我们理解了正在工作的业务Domain后， 就可以得出这样的结论：Domain model是真实世界中问题的描述。

这个解释让我想起来了，刚开始学面向对象编程的学术定义：“一个类是描述真实世界里的实体行为和属性方式。”

如果最终跟着这个系列的博客， 你将理解到DDD帮助你确切地实现面向对象设计。

DDD不是架构

刚开始时，DDD被理解成一组模式和软件开发的最佳实践。

如果你说某个项目使用了DDD， 是因为它使用了Entities、Services和Repositories。而一些情况下，DDD也体现在Value Objects, Aggregates, Events, Modules和Factories的话，我会说，你错了。

针对使用DDD的这种方式， 我们称之为DDD-Lite。 简单来说， DDD-Lite会导致糟糕的Domain Model设计。  

DDD的体系结构

基于我对DDD的 DDD使用经验和阅读过的书， 这些书有《Eric Evans, Domain-Driven Design – Tackling Complexity in the Heart of Software》、《Vaughn Vernon, Implementing Domain-Driven Design》和《Vaughn Vernon, Domain-Driven Design Distilled》， 我归纳出来， DDD有三个系列的概念：  

战略设计：也称为战略建模，核心目标是定义Bounded contexts, Ubiquitous Language和Context Map， 期间团队一起参与。 

战术设计：也称为战术建模，这是DDD实施时的“砖头”，包含Entities, Services, Repositories, Value Objects, Aggregates, Events, Modules和Factories等。 

架构设计：这一系列的概念指DDD中使用的架构样式， DDD落地时， 可以使用Hexagonal、Layered Architecture或CQRS架构样式。 

咱需要确切地理解每一个核心概念后， 才实际地做出正确的DDD设计。

后续的文章中， 将详细描述这些基本概念。

结论：

我们搞软件是为了帮助咱解决实际业务中的问题，如果搞出的软件没能帮到业务，就无从谈起了。

DDD就是可以帮咱提升软件建设的速度与质量。

使用DDD并不轻松，需要条分缕析地说服自己DDD确实有用后， 才得心应手地使用。另一方面，如果业务逻辑不复杂的话，使用DDD会得不偿失。