再谈领域驱动设计

最近，我读了埃里克·埃文斯（Eric Evans）的一本书，名为《 域驱动设计》 。 这不是我第一次阅读本书，但是这一次我意识到我对域驱动设计完全错了。

我认为领域模型由实体和值对象组成。 实际上，我痴迷于将域逻辑移至实体和值对象。 我想做的很糟糕，以至于我忽略了一个关键的警告。

我的代码比以前更整洁，但是我始终觉得自己遗漏了一些东西 。

当我第二次阅读域驱动设计时，我意识到自己错过了什么。

领域模型的基础

我的错误是我对实体和值对象如此着迷，以至于忘记了域模型的其他构建块 。

域驱动设计对域模型的描述如下：

域模型不是特定的图； 该图旨在传达该想法。 这不仅仅是领域专家头脑中的知识； 它是对该知识的严格组织和选择性抽象。 图表可以表示和交流模型，精心编写的代码也可以表达英语，句子也可以表达。

但是，阅读这个定义并没有改变我的想法。 实际上，当我阅读它时，我为自己感到骄傲，因为它似乎证明我在做正确的事。

然后，我开始阅读本书的第二部分，该部分讨论了模型驱动设计的基本组成部分以及我精心制作的纸牌屋，它们分崩离析。

本部分认为，模型驱动的设计具有以下构建基块：

• 实体是由其身份定义的对象。 换句话说，如果对象的标识在整个生命周期中都保持不变，则应将该对象建模为实体。
• 值对象描述事物的属性，并且它们没有自己的标识或生命周期。 通常，它们的生命周期绑定到实体的生命周期。
• 服务包含不属于实体或值对象的操作。 如果您觉得对实体或值对象添加操作不自然，您很可能应该将此操作添加到服务中。
• 模块（包装）用于减少认知负担。 它们使开发人员可以研究单个模块的内部而不关注其他模块，或者研究模块之间的关系而无需关注实现细节。
• 集合是一组对象，它们被视为一个单元。 每个聚合都有一个根对象，该根对象用于访问聚合的其他对象。 每个聚合还具有边界，该边界定义哪些对象属于所讨论的聚合。
• 工厂用于封装对象或集合的创建逻辑。 如果创建逻辑很复杂或过多地揭示了创建对象的内部结构，则工厂很有用。
• 存储库用于从使用的数据存储中获取实体并将实体的信息保存到其中。

在完成本书之后，我别无选择，只能承认我不知道什么是领域驱动设计。

好消息是我还有很多时间可以学习。

我学到了什么？

我第二次阅读域驱动设计所学到的最大知识现在应该很明显，但是我也吸取了其他一些教训：

• 我了解了应用程序服务和域服务之间的区别。 应用程序服务协调任务并将工作委托给域对象。 域服务实现的操作不属于实体或值对象。 换句话说，应用程序服务不包含业务逻辑，而域服务则包含业务逻辑。
• 我知道领域模型不必是现实的精确副本。 我可以简单地选择现实中对我有用的部分，而忽略其余部分。 乍一看似乎很明显，但也很容易忘记这一点。

我的下一步是了解有关域驱动设计的更多信息。 更具体地说，我想弄清楚如何在日常工作中使用这些构建基块。 这就是为什么我已经由Vaughn Vernon订购了实现域驱动设计的原因 。

下一步是什么？

翻译自: https://www.javacodegeeks.com/2014/04/domain-driven-design-revisited.html