Architecture 这是不是；贫血“；模型可接受的设计？

首先我想说的是，我不是在试图在我当前的设计中实现一个领域模型

话虽如此，我目前正在构建一个如下所示的体系结构：

UI DTO <=> Service DTO <=> Business/Database DTO (using AutoMapper)

UI-DTO-Service-DTO-Business/Database-DTO（使用AutoMapper）

我一直在阅读，也一直在观看，我害怕贫血模型。即使我没有给DDD开处方，我也不想创建太多的层，这样就很难来回映射非常相似的东西

然而，我有这样设置的全部原因是双重的。易于改变和默默无闻

• 易于更改：如果我的公共对象通过我的服务公开，并且我在内部使用UI和业务对象，那么我可以更自由地进行更改，而不会破坏现有的API。但是，如果DTO开始偏离，也许我可以使用一个DTO并进行重构
• 隐晦性：我可以公开我的公共对象，但如果它们是内部的，就不能公开我的完整对象及其实现。这将需要一个安全的产品，所以我正在为此做准备。但是，也许我以后可以重构它

所以，我的问题是：我目前的模型有意义吗，还是我以后会问问题？这些对象主要是DTO，这样可以吗？即使在Evan的书中，他也暗示，如果计划在不同的服务器上分发，那么这个模型是可以的？因此，仅出于这个原因，我的分层就可以了吗？因为我计划让UI、服务和DB层能够在不同的服务器上运行（它们目前不需要）

---

我只是想了解架构过度，但同时又试图避免架构不足……那么，这种模型结构对我当前的实现是好是坏？

这是我的团队使用ASP.NET MVC和WCF进行开发时使用的模式，其中您的业务/数据库dto映射到实体框架类，您的服务dto映射到传入/传出WCF服务的POCO类/数据契约，而您的UI dto映射到MVC模型

虽然这似乎是多余的，但对于堆栈中所有三个dto都具有相同属性的设计来说，每一层的需求很少适用。它们往往不同的一个例子是将外键放入查找表中。在数据库层，这将由int表示，而在服务层，这将更好地建模为enum，以便实施类型安全性，最后，在ui中，所述字段将转换为本地化字符串以显示给用户

关于你对过度设计的恐惧，有一些关于保持简单的事情要说。促使我使用这种模式的原因是，我需要独立于ui部署应用程序层，或者我需要在一个有两个以上开发人员的团队中工作。随着团队的发展，团队成员决定绕过您的业务层，直接与数据库对抗的可能性显著增加。在这样做的过程中，它们总是无法达到您现有的任何面向方面编程的目的——即，事务中不会记录或包装内容。添加额外的层并将其移动到一个单独的服务器上可以创建一个干净的关注点分离，更重要的是，可以强制执行它。一个一两个人的团队可能会有足够的纪律来避免这种情况，但是，随着您的成长，它很快就会成为一种必要

希望有帮助

我首先要说的是，我并不是在试图实现一个领域模型

我害怕贫血模型

这两个对我来说似乎有点矛盾

即使我没有开DDD的处方，我也不想太多 许多层表示，保持映射非常相似的东西会让人感到痛苦 来来回回

DDD中提出的贫血症或富域模型的概念并不假设您拥有的层数、这些层使用的数据结构以及这些数据结构如何从一层转换到另一层

富域模型只意味着您的业务层包含除数据外还封装行为的域对象。您完全可以拥有一个丰富的内部域模型，只将公共服务作为其行为的门面公开，如果您愿意，您可以在其下面拥有10亿层，每个层都操纵自己的DTO类型

所以，我的问题是：我目前的模型有意义吗，还是我以后会问问题？[…]我只是想意识到过度架构，但同时 是时候尽量避免在架构下

---

你的模型看起来一点也不像是过度设计的。它只反映分层应用程序中的自然层。正如Doug所说，DTO在每一层中都有点不同是正常的，因为它们的用途不同。

但是，在我目前的情况下，它们在每一层中都是相同的，这就是为什么为了“以防万一”而将对象串出来似乎有些过分了