为什么应该将域实体与表示层隔离？

Question

领域驱动设计的一部分似乎没有太多细节，那就是如何以及为什么应该将领域模型与界面隔离。 我试图让我的同事相信这是一个很好的实践，但我似乎没有取得太大进展......

他们在表示层和界面层中随心所欲地使用域实体。 当我向他们争论他们应该使用显示模型或 DTO 将领域层与界面层隔离时，他们反驳说，他们没有看到这样做的业务价值，因为现在你有一个 UI 对象需要维护以及原始域对象。

所以我正在寻找一些可以用来支持这一点的具体原因。 具体来说：

1. 为什么我们不应该在表示层中使用域对象？
   （如果答案是显而易见的，“解耦”，那么请解释为什么这在这种情况下很重要）
2. 我们是否应该使用其他对象或构造来将域对象与接口隔离？

Answer 1

另请参阅下面的“层之间的数据传播”部分，我认为该部分提出了令人信服的论点：

http://galaxy.andromda.org/docs/andromda-documentation/andromda-getting-started-java/java/index.html

Answer 2

借助“值注入器”等工具以及表示层中“映射器”的概念，同时使用视图，更容易理解每​​段代码。 如果你有一点代码，你不会立即看到优势，但是当你的项目越来越大时，你会很高兴使用视图而不必进入服务的逻辑，存储库来理解视图模型。 View Model 是广阔的反腐败层世界中的另一个守卫，在长期项目中价值不菲。

我认为使用视图模型没有优势的唯一原因是，如果您的项目足够小且简单，可以将视图直接绑定到模型的每个属性。 但是，如果将来需求发生变化，视图中的某些控件将不会绑定到模型，并且您没有视图模型概念，那么您将开始在许多地方添加补丁，并且您将开始拥有遗留代码你不会欣赏。 当然，您可以进行一些重构，以在视图视图模型中转换视图模型，并遵循 YAGNI 原则，同时如果不需要，则不添加代码，但对我自己来说，这更是我必须遵循的最佳实践，以添加表示层仅公开视图模型对象。

Answer 3

I'm trying to convince my colleagues that this is a good practice

为了良好实践而采取的良好实践并不总是具有商业效率。 如果有道理的话，我非常乐意反对使用 CQRS、事件溯源、DDD 等。例如，在具有一两个用例的小型项目上。

虽然其他答案非常好，但没有提到让我相信解耦很重要的问题：您的存储库 (ORM) 可能会意外填充数据。

例如，考虑访问实体框架的这两个操作DbContext：
（我没有测试过这段代码，但它应该能说明问题）

public JsonResult GetUser(string id) {
  return new JsonResult(_ctx.Users.FindOne(u => u.id == id));
}

public JsonResult AddUser(string id) {
  var currentUser = _ctx.Users.Include(u => u.Roles).FindOne(currentUserId); // <--
  if (!currentUser.Roles.Contains("Administrator")) throw new Exception("User not authorized to add new users");  

  _ctx.Users.Add(new User(id));

  return new JsonResult(_ctx.Users.FindOne(u => u.id == id));
}

虽然两个操作都返回用户的 JSON 对象，但由于实体框架的对象缓存，第二个操作将包含 Roles 属性——没有在最后一行明确要求。

如果您的应用程序或持久性/基础设施层有条件地包含属性，那么您的域对象属性将被有条件地实例化，并且您可能会得到意外的结果。

由于这一点，以及其他答案提供的重要原因，我确信不再将我的域对象暴露给我的表示层。

最后，我并不反对使用匿名对象来代替 Dto，尤其是当 JsonResult 失去类型安全性时。

例如：

public JsonResult GetUser(string id) {
  var user = _ctx.Users.FindOne(u => u.id == id);
  return new JsonResult(new {
    id = user.id,
    name = user.name,
  })
}

public JsonResult AddUser(string id) {
  var currentUser = _ctx.Users.Include(u => u.Roles).FindOne(currentUserId); // <--
  if (!currentUser.Roles.Contains("Administrator")) throw new Exception("User not authorized to add new users");  
  
  _ctx.Users.Add(new User(id));

  var user = _ctx.Users.FineOne(u => u.id == id);

  return new JsonResult(new {
    id = user.id,
    name = user.name,
  })
}

Answer 4

在通用语义和特定领域语义之间添加额外映射的唯一合理原因是，您拥有（访问）基于与领域语义不同的通用（但可映射）语义的现有代码（和工具）主体。

领域驱动设计在与一组正交的功能域框架（例如 ORM、GUI、工作流等）结合使用时效果最佳。 永远记住，只有在外层邻接中才需要暴露域语义。 通常这是前端 (GUI) 和持久后端 (RDBM、ORM)。 任何有效设计的中间层都可以而且应该是域不变的。

Answer 5

很简单，原因之一是实施和漂移。 是的，您的表示层需要了解您的业务对象才能正确表示它们。 是的，最初看起来两种类型的对象的实现之间有很多重叠。 问题是，随着时间的推移，双方都会增加一些东西。 表示发生变化，表示层的需求不断发展以包含完全独立于业务层的内容（例如颜色）。 同时，您的领域对象会随着时间的推移而发生变化，如果您没有与接口进行适当的解耦，那么您就会冒着对业务对象进行看似良性的更改而搞砸接口层的风险。

就我个人而言，我认为处理事物的最佳方式是通过严格执行的接口范例； 也就是说，您的业务对象层公开一个接口，这是与其通信的唯一方式； 没有公开有关接口的实现细节（即域对象）。 是的，这意味着您必须在两个位置实现域对象； 你的接口层和BO层。 但是，这种重新实现虽然最初看起来像是额外的工作，但有助于加强解耦，这将在未来的某个时候节省大量的工作。

Answer 6

我自己也曾为此苦苦挣扎。 在某些情况下，DTO 在演示中使用是有意义的。 假设我想在我的系统中显示公司的下拉列表，并且我需要它们的 id 来绑定值。

好吧，我可以发回带有名称和 ID 的 DTO，而不是加载可能引用订阅或谁知道还有什么的 CompanyObject。 恕我直言，这是一个很好的用途。

现在再举一个例子。 我有一个代表估计的对象，该估计可能由劳动力、设备等组成，它可能有用户定义的大量计算，这些计算将所有这些项目进行汇总（每个估计可能因不同类型而不同的计算）。 为什么我必须为这个对象建模两次？ 为什么我不能简单地让 UI 枚举计算并显示它们？

我通常不使用 DTO 将域层与 UI 隔离。 我确实使用它们将我的域层与我无法控制的边界隔离开来。 有人将导航信息放入其业务对象的想法是荒谬的，不要污染您的业务对象。

有人会在他们的业务对象中进行验证的想法吗？ 嗯，我说这是一件好事。 您的 UI 不应该独自负责验证您的业务对象。 您的业​​务层必须进行自己的验证。

为什么要将 UI 生成代码放在业务对象中？ 就我而言，我有单独的对象，它们与 UI 分开生成 UI 代码。 我有单独的对象，它们将我的业务对象呈现为 Xml，必须分离各层以防止这种类型的污染的想法对我来说是如此陌生，因为为什么要将 HTML 生成代码放入业务对象中......

编辑
我想多一点，在某些情况下，UI 信息可能属于领域层。 这可能会使您所谓的域层变得模糊，但我开发了一个多租户应用程序，该应用程序在 UI 外观和感觉以及功能工作流程方面都有非常不同的行为。 取决于各种因素。 在本例中，我们有一个代表租户及其配置的域模型。 它们的配置恰好包含 UI 信息（例如通用字段的标签）。

如果我必须设计我的对象以使其可持久化，我是否还必须复制这些对象？ 请记住，如果您想添加新字段，现在您有两个位置可以添加它。 也许这会引发另一个问题，如果您使用 DDD，所有持久实体都是域对象吗？ 我知道在我的例子中他们是。

Answer 7

我不同意。

我认为最好的方法是从表示层中的域对象开始，直到有意义为止。

与流行的看法相反，“域对象”和“值对象”可以在表示层中愉快地共存。 这是最好的方法 - 您可以获得两个世界的好处，减少域对象的重复（和样板代码）； 以及跨请求使用值对象的剪裁和概念简化。

Answer 8

这样做的原因与将 SQL 排除在 ASP/JSP 页面之外的原因相同。

如果您只保留一个域对象，用于表示层和域层，那么该对象很快就会变得单一。 它开始包括UI验证代码、UI导航代码和UI生成代码。 然后，您很快就会在其上添加所有业务层方法。 现在你的业务层和UI都混在一起了，而且都在领域实体层搞乱了。

您想在另一个应用程序中重用这个漂亮的 UI 小部件吗？ 好吧，您必须创建一个具有此名称、这两个模式和这 18 个表的数据库。 您还必须配置 Hibernate 和 Spring（或您选择的框架）来进行业务验证。 哦，你还必须包含这85个其他不相关的类，因为它们是在业务层中引用的，而恰好位于同一个文件中。

Answer 9

答案取决于您的应用程序的规模。

---

简单的 CRUD（创建、读取、更新、删除）应用程序

对于基本的 CRUD 应用程序，您没有任何功能。 在实体之上添加 DTO 会浪费时间。 它会增加复杂性，但不会增加可扩展性。

---

中等复杂的非 CRUD 应用程序

在这种规模的应用程序中，您将拥有很少的实体，这些实体具有真正的生命周期以及与之相关的一些业务逻辑。

在这种情况下添加 DTO 是一个好主意，原因如下：

• 表示层只能看到实体拥有的字段的子集。 您封装实体
• 后端和前端之间没有耦合
• 如果您在实体内部有业务方法，但在 DTO 中没有，那么添加 DTO 意味着外部代码不能破坏实体的状态。

---

复杂的企业应用

单个实体可能需要多种表示方式。 他们每个人都需要不同的字段集。 在这种情况下，您会遇到与前面的示例相同的问题，并且需要控制每个客户端可见的字段数量。
为每个客户端提供单独的 DTO 将帮助您选择应该可见的内容。

Answer 10

我们在服务器和用户界面上使用相同的模型。 这很痛苦。 有一天我们必须重构它。

问题主要是因为领域模型需要被分割成更小的部分，以便能够在不引用整个数据库的情况下对其进行序列化。 这使得在服务器上使用变得更加困难。 缺少重要链接。 有些类型也不可序列化，无法发送到客户端。 例如“类型”或任何通用类。 它们需要是非通用的，并且类型需要作为字符串传输。 这会生成额外的序列化属性，它们是多余且令人困惑的。

另一个问题是 UI 上的实体并不真正适合。 我们正在使用数据绑定，许多实体有大量冗余属性仅用于 ui 目的。 此外，实体模型中还有许多“BrowsableAttribute”和其他属性。 这实在是太糟糕了。

最后，我认为这只是哪种方式更容易的问题。 在某些项目中，它可能可以正常工作，并且不需要编写另一个 DTO 模型。

Answer 11

该死，我发誓这就是坚持。

不管怎样，这是同一件事的又一个例子：帕纳斯定律说模块应该保守秘密，而秘密是可以改变的要求。 （鲍勃·马丁（Bob Martin）有一个规则，这是这个规则的另一个版本。）在这样的系统中，演示可以独立于域而改变。 例如，一家公司以欧元维持价格并在公司办公室使用法语，但希望以美元显示价格并使用普通话文本。 域是相同的； 演示文稿可能会改变。 因此，为了最大限度地减少系统的脆弱性（即为了实现需求变更而必须更改的事物的数量），您可以将关注点分开。

Answer 12

这在很大程度上与依赖关系有关。 组织的核心功能结构有其自身的功能需求，UI应使人们能够修改和查看核心； 但核心本身不需要容纳 UI。 （如果需要发生，通常表明核心不是设计的。）

我的会计系统有一个结构和内容（和数据），应该模拟我公司的运营。 无论我使用什么会计软件，这种结构都是真实存在的。 （一个给定的软件包不可避免地包含其自身的结构和内容，但部分挑战是最大限度地减少这种开销。）

基本上，一个人有一份工作要做。 DDD 应与工作流程和内容相匹配。 DDD 旨在明确所有需要完成的工作，并尽可能完全且独立地完成。 然后，UI 希望有助于尽可能透明、尽可能高效地完成工作。

接口是关于为正确建模和不变的功能核心提供的输入和视图。

Answer 13

您的演示文稿可能引用您的域层，但不应该直接从您的用户界面绑定到您的域对象。 域对象不适合 UI 使用，因为如果设计得当，它们通常是基于行为而不是数据表示。 UI 和 Domain 之间应该有一个映射层。 MVVM，或 MVP，是一个很好的模式。 如果您尝试将 UI 直接绑定到域，您可能会给自己带来很多麻烦。 他们有两个不同的目的。

Answer 14

这是一个真实的例子，说明了为什么我认为将域实体与视图分开是一种很好的做法。

几个月前，我创建了一个简单的 UI，通过一系列 3 个仪表显示土壤样本中氮、磷和钾的值。 每个仪表都有一个红色、绿色和红色部分，即每个组件的数量可能太少或太多，但中间有一个安全的绿色水平。

没有太多考虑，我对业务逻辑进行了建模，以提供这 3 种化学成分的数据和一个单独的数据表，其中包含有关 3 种情况中每种情况下可接受水平的数据（包括使用的测量单位，即摩尔或百分比）。 然后，我使用一个非常不同的模型对 UI 进行建模，该模型关注仪表标签、值、边界值和颜色。

这意味着当我后来必须显示 12 个组件时，我只需将额外的数据映射到 12 个新的仪表视图模型中，它们就会出现在屏幕上。 这也意味着我可以轻松地重复使用仪表控件并让它们显示其他数据集。

如果我将这些仪表直接耦合到我的域实体中，我将不会拥有任何上述灵活性，并且任何未来的修改都会令人头疼。 在用户界面中建模日历时，我遇到过非常类似的问题。 如果要求日历约会在有 10 名以上与会者时变为红色，则处理此问题的业务逻辑应保留在业务层中，并且 UI 中的所有日历都需要知道，它已被指示变红，应该不需要知道为什么。

Answer 15

也许您没有从足够广泛的角度来概念化 UI 层。 考虑多种形式的响应（网页、语音响应、印刷信件等）和多种语言（英语、法语等）。

现在假设电话呼入系统的语音引擎运行在与运行网站的计算机（可能是 Windows）完全不同类型的计算机（例如 Mac）上。

当然，很容易陷入“在我的公司，我们只关心英语，在 LAMP（Linux、Apache、MySQL 和 PHP）上运行我们的网站，并且每个人都使用相同版本的 Firefox”的陷阱。 但5年或10年后呢？