领域驱动设计之领域模型_在领域驱动的设计，贫乏的领域模型，代码生成，依赖项注入等方面……...

领域驱动设计之领域模型

埃里克·埃文斯（Eric Evans）已制定了域驱动设计（DDD）。 Martin Fowler是DDD的大力支持者和拥护者。这些都是非凡的名字，几乎可以肯定的是，他们正在支持一些有价值的东西。我不是在这里争论。也许我正在试图证明我编写软件的方式的合理性，或者也许我只是试图清除事物并具有建设性。让我们来看看。

什么是领域驱动设计的核心- 域， 域模型 ， 通用语言的抽象的概念。我不会对此进行详细介绍–对于那些感兴趣的人，有维基百科（在页脚中有很多参考文献可供阅读）。从理论上讲，这都是非常好的，并且域驱动的构建软件的方式应该对所有人都有吸引力–毕竟，构建该软件是为了该领域的利益，而不是建筑师，开发人员或QA的利益。

但是现在是实际部分–如何实施DDD？我将在当代的背景下回答这个问题，即使用spring和hibernate之类的框架。我会证明它们的用法合理。 Spring是一个非侵入性的依赖注入框架。 Fowler也强烈支持DI，并且DI被认为是实现DDD的好方法。 Hibernate是使用关系数据库时使用对象的一种方法。另一种方法是使用JDBC并手动构造对象，但这很繁琐。因此，Hibernate不会影响体系结构部分-它是一种实用程序（当然，功能非常强大）。

在本文中，我将使用“Hibernate”和“弹簧”作为“给定的”，尽管它们可以通过任何DI框架以及任何依赖对象的ORM或其他持久性机制进行更改。

用spring和hibernate实现DDD的公认方法是：

使用@Configurable使域对象有资格进行依赖注入（它们不会在spring之前实例化，因此它们需要这种特殊方法）
在域对象中注入存储库对象，以允许域对象执行与持久性相关的操作
使用薄的，无状态的事务服务层（外观）来协调域对象

这篇广泛的文章中介绍了这种方法的实现和描述。另一个示例（没有Spring）是http://dddsample.sourceforge.net/ 。稍后再讨论。

这种方法的替代方法是贫血域模型。它被认为是一种反模式，但同时非常普遍并且经常使用。贫血数据模型的功能很简单–域对象内部没有业务逻辑–它们只是数据持有者。而是将业务逻辑放在服务中。

之所以将其视为反模式，是因为，首先，这似乎是一种程序方法。它破坏了封装，因为对象的内部状态完全不是内部状态。其次，由于领域对象是设计的中心，因此如果它的操作不属于它，而改为多个无状态服务类，则很难更改它。域驱动的设计针对中型到大型应用程序，这些应用程序发生了很大变化，并且需要一种简便的方法来快速进行更改，而又不会破坏其他功能。因此，在对象本身内具有对象的所有功能非常重要。这也可以确保减少重复代码。

因此，代替让服务来计算价格： ProductServiceImpl.calculatePrice（complexProduct），我们应该简单地拥有ComplexProduct.calculatePrice（） 。因此，每当领域专家说价格计算机制发生变化时，更改的地方恰好是一种，也是最直接的一种。

如果考虑简单的操作，这看起来很容易。但是，当一个域对象需要另一个域对象来完成其工作时，它将变得更加复杂。使用贫血数据模型，只需将另一个Service注入当前Service并调用其方法即可实现。使用建议的DDD，可以通过将域对象作为参数来实现。

在我看来，域对象（也是Hibernate实体）已经设置了依赖项。但不是在Spring之前，因为Spring无法确切知道要注入哪个领域对象。它们由Hibernate“注入”，因为它确切知道应将哪个（由主键标识）域对象放置在另一个域对象中。因此，有一个奇怪的例子–如果产品腐烂并且必须在仓库中分配气味，则必须调用例如Warehouse.increaseSmellLevel（getSmellCoeficient（）） 。而且它有精确的仓库，不受弹簧的干扰。

现在，我不同意这一点。大多数来源（包括上面链接的两个来源）都指出应将存储库/ DAO注入域对象中。不，他们不应该。只需调用“保存”或“更新”就不需要了解对象的内部状态。 Hibernate仍然知道一切。因此，我们只是将整个对象传递到存储库。

让我们将其分为两个部分： 业务逻辑和基础架构逻辑 。域对象不应该了解基础结构。那可能意味着它不应该知道它被保存在某个地方。产品是否关心其存储方式？不，这是“感兴趣”的存储机制。这里是实际的缺点：

CRUD通过简单地将存储库调用包装在所有域对象中来实现–代码重复
域对象可传递地依赖于持久性–即它不是纯域对象，并且如果存储库发生更改，则也必须对其进行更改。从理论上讲，仅当域规则和属性更改时，才应更改
人们很容易将事务，缓存和其他逻辑包含在域对象中

在上面的一篇文章中，我将在此处为建议的解决方案打开一个括号，以使代码重复和样板代码更易于处理。建议生成代码。而且我认为代码生成是一种罪过。它将无法删除重复的或非常相似的代码并将其抽象化为工具。最引人注目的示例是生成ProductDAO，CategoryDAO，WarehouseDAO等。生成的代码难以管理，无法扩展且严重依赖于外部元数据，这绝对不是面向对象的方法。

说到存储库，在建议的示例中，每个域对象都应该有一个存储库，该存储库又将调用持久性机制。那我们得到什么：

用户在UI中按“保存”>保存在服务上的UI调用（以便获得事务支持）>保存在域对象上的服务调用>保存在资源库上的域对象调用>保存在持久性机制上的资源库调用>持久性机制保存对象。

是我自己，还是在这里调用域对象是多余的。这是一种不增加任何内容的直通方法。而且由于很多功能与CRUD相关（是的，即使在大型企业应用程序中也是如此），这对我来说似乎很糟糕。

最后，我发现@Configurable方法是一个hack。它在后台做了一些魔术，这不是任何通用语言功能（也不是设计模式），并且为了了解它是如何发生的，您需要大量的经验。

所以，总结上面的大混乱