总览

绑定模型和实现

领域驱动设计不仅能够指导早期的分析工作，还应该成为设计的基础。

这才是关键，如何通过领域模型设计出领域产物。

由于在创建分析模型的时候并没有考虑程序设计的问题，因此分析模型可能不能满足程序设计的需求。

在编码开始后，如果开发人员不得不重新对设计进行抽象，那么大部分的领域知识就会被丢弃。

领域驱动设计不再将分析模型和程序设计分开，而是寻找能够满足这两个方面的单一模型。以更高的标准来完成两个完全不同的目标。如果模型对于程序的实现显得不实用的时候，重新设计，如果无法描述模型的关键概念，重新设计。

为什么模型至关重要

系统上下层结构的不匹配很容易导致误解。比如收藏网页的时候，IE 浏览器会报文件名错误。用户就不知道文件名是什么。建议整体只有一套模型。

软件开发过程中职责不能过度分离，分析，建模，设计和编程工作过度分离会对整体产生不良影响。因为如果编写代码的人觉得对模型没有必要负责，那么模型和程序的关联就会越来越弱。领域驱动设计的两个要素(支持有效的实现并抽象出关键的领域知识)就丢失了一个了。

任何建模的技术同学，都必须花时间了解代码，每一个开发成员都必须不同程度的参与模型讨论并且与领域专家保持联系。

模型是大家公共的职责！！！

分离领域

虽然专门用于解决领域问题的那部分通常只占软件系统很小的一部分，但却出乎意料的重要。就是经常使用的分层技术。

前端也要单独分出领域层，领域层里装的是业务的核心。

层与层之间的依赖关系只能是单向的。

就像模块之间的依赖只能是单向的一样，一旦循环依赖就会很风险。

领域隔离的最大好处就是可以专注于领域设计，而不用考虑其他的方面。

软件中的模型

很多时候多对多关联的关系我们可以通过限定遍历方向来编程一对多的关系。

entity

用标识定义。而不是属性定义的事物就是 entity。

这个东西其实在我们的项目里就被错叫成“domainmodal”，不对，也不太一样，我们的 domainmodal 其实是个数据库

对于 entity，我们只添加对概念至关重要的行为和行为必须的属性。将行为和属性转移到与核心实体关联的其他对象中。

value objact

用于描述领域的某个方面，而本身没有概念标识的对象就是 value object。我们只关心他们是什么，而不关心他们是谁。不关心是哪个实例。

value object 本身为性能优化提供了更多选择，他们可能为数众多，但是只需要一个实例。

和享元模式的理念契合。

service

重要的领域操作不能放到 entity 和 value object 中，这些操作从本质上讲是活动或动作，并不是对象，他们就应该是一个 service。

如果不将这些行为放到一个对象上，就会慢慢地转化为过程式的编程。当我们把一个操作放到不属于对象定义的对象时，这个对象就会产生意念上的混淆。可以避免混淆真正的模型对象。

好的 service 的 3 个特征：

• 与领域概念相关的操作不是 entity 或 value object 的一个自然组成部分

• 接口根据领域模型的其他元素定义

• 操作是无状态的

也就是业务逻辑不知道放在哪里的时候就比较合适成为一个 service。

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 981909093@qq.com