这种“贫血”模型是否可以接受？

Question

我首先要说的是不尝试在我当前的设计中完成域模型。

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

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

我一直在阅读Eric Evan's DDD book，并且还看过Greg Young's 7 reasons why DDD projects fail，并且害怕贫血模型。即使我没有开DDD处方，我也不想创建太多的图层，因此不断地来回映射非常相似的事情会变得很困难。

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

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

所以，我的问题是：我现在的模型是否有意义，或者我以后会问问题？没关系，因为这些对象主要是DTO的？即使在Evan的书中，他暗示如果计划将该模型分布在不同的服务器上，这个模型还可以吗？所以，我的分层是否仅仅因为这个原因，我计划让UI，服务和数据库层能够在不同的服务器上（它们目前不需要它们）？

我只是想要了解过度架构，但同时试图避免架构下.....所以，这种模型结构对我当前的实现是好还是坏？

Answer 1

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

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

关于你对过度建筑的担心，关于保持简单，有一些事情可以说。驱使我使用这种模式的力量是我需要独立于我的ui部署我的应用程序层，或者仅仅是我在一个拥有两个以上开发人员的团队中工作。随着团队的发展，团队成员决定绕过业务层并直接针对数据库的可能性会大大增加。在这样做的过程中，他们总是会破坏你所拥有的任何面向方面编程的目的 - 即。东西不会被记录或包装在事务中。添加额外的图层并将其移动到单独的服务器可以创建一个清晰的关注点分离，更重要的是，可以强制执行它。一个或两个人的团队可能会受到足够的纪律处分以避免这种情况，但是，随着您的成长，它变得非常必要。

希望有所帮助！

Answer 2

  

我首先想说的是我并没有尝试完成域模型

...

  

并且害怕贫血模型

这两个似乎与我有点矛盾。

  

即使我没有开DDD，我也不想创作   在很多层中，保持映射非常相似的东西变得很痛苦   来回。

DDD中建议的贫血或富域模型的概念并未假设您拥有的层数，这些层使用的数据结构以及这些数据结构如何转换并从一层传递到另一层

富域模型仅表示您的业务层包含除数据外还封装行为的域对象。您可以完美地拥有丰富的内部域模型，并且只公开作为其行为外观的公共服务，并且如果您愿意，则在下面有十亿个层，每个层都操纵它自己的DTO类型。

  

所以，我的问题是：我现在的模型是否有意义，或者我以后会问问题？ [...]我只是想要了解过度架构，但同时也是如此   时间试图避免建筑不足..

您的模型看起来不像过度架构。它仅反映分层应用程序中的自然层。就像Doug说的那样，DTO在每一层中都有点不同，这是正常的，因为它们没有同样的目的。