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会得不偿失。

---------

往期推荐

  1. XX

  2. YY

~~~~~~~~~~~~~

长按二维码,关注公众号

一起推进电商业务信息化

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章