design-patterns - 丰富的领域模型和 ORM

Question

Martin Fowler 将贫血领域模型视为一种反模式。

由于 Object Relational Impedence Missmatch，将持久性模型作为域模型滚动似乎也很严重。 .出于持久性和规范化的考虑，我们倾向于将类分解为非常小的小块，在这些类之上添加方法是愚蠢的。此外，持久性很少改变，但业务逻辑会发生相当大的变化。

因此，我们需要一个建立在持久性模型上的 DomainModel(而不是一模一样)。这个领域模型将包含业务逻辑属性和方法。

但是现在这些领域模型仍然在服务后面，为了将它们暴露给外界，我们需要将它们转换为 DTO。

我们在这里做了很多映射。

对领域模型的持久性

将领域模型转换为 DTO 以在服务之间传递

它并没有就此结束，因为可能需要将 DTO 映射到 ViewModel 中。

所有这些以及重复验证逻辑的问题仍然没有消失，因为客户端需要实时验证。 ViewModel 对验证一无所知，因此例如在 SPA 中，您被迫在客户端(通常在 javascript 中)再次重写验证逻辑。

服务本质上也是无状态的(面向消息或 RPC)，所以我们正在做所有这些映射，在持久性，面向对象之间，然后回到程序，有什么好处？您如何从大多数 IT 预算的实际角度证明成本的合理性？

我知道拥有完整的 DDD、聚合根、域模型等会很“酷”，但是你如何证明成本和开发生产力受到的打击是合理的？

anti-pattern (or antipattern) is a pattern used in social or business operations or software engineering that may be commonly used but is ineffective and/or counterproductive in practice

如果是这样，与“精益”域模型相比，DDD 和富域模型是否更适合上面的反模式定义。对不起，我鄙视这个词，“贫血”。

通过保持领域模型、“精益”，您实际上允许在不违反“抽象依赖原则”、“不要重复自己”以及将一个数据载体映射到另一个数据载体的耗时、乏味和容易出错的过程的情况下共享它，以及任何与之相关的单元测试(除非您正在考虑进行无单元测试的映射并希望最好)。

Answer 1

似乎您混淆了很多概念，将丰富的域模型方法归咎于它不直接负责的事情。

富域模型与分层架构是正交的，尤其是富域模型并不决定您拥有的层数、这些层之间应该交换哪些数据结构以及它们应该如何映射。

富域模型与验证正交，并没有说明除了后端验证之外还需要进行客户端检查。

换句话说，使您的域模型对服务中的所有业务逻辑都缺乏活力并不一定会使您免于编写大量样板 DTO 映射代码，也不会消除客户端“双重检查”的需要(这是由一种普遍接受的最佳实践)。

这并不意味着您关于成熟的多层架构的成本和重量的观点是无效的。您可能会对 Mark Seemann 讨论类似问题的这篇文章感兴趣: http://blog.ploeh.dk/2012/02/09/IsLayeringWorthTheMapping.aspx