1

我首先想说的是，我并不想在我当前的设计中完成一个领域模型。

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

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

我一直在看Eric Evan 的 DDD 书，也看过Greg Young 的 DDD 项目失败的 7 个原因，害怕贫血模型。即使我没有规定 DDD，我也不想创建太多层，以致于来回映射非常相似的东西会变得很痛苦。

但是，我进行设置的全部原因有两个。易于更改和晦涩难懂

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

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

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

4

2 回答 2

2

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

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

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

希望有帮助！

于 2012-11-07T05:40:48.310 回答
0

我首先想说我不是在尝试完成一个领域模型

...

并且害怕贫血模型

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

即使我没有规定 DDD，我也不想创建太多层，以致于来回映射非常相似的东西会变得很痛苦。

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

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

所以，我的问题是：我当前的模型是否有意义，或者我稍后会提出问题？[...] 我只是想了解过度架构，但同时试图避免架构不足..

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

于 2012-11-07T12:40:19.410 回答