在领域对象中实现应用程序级别和UI级别接口

Question

我正在构建一个应用程序，允许工程师配置“索具”（即您举升的物体与举升它所用的起重机之间的电缆）。我们是一个由两人组成的远程团队，由于时区和其他项目的原因，沟通有点稀疏。我有一个关于如何最好地构建领域层的问题，特别是使用接口来允许我们更独立地工作是否被认为是最佳实践。

应用程序的核心是“绑定”的域模型，它是一个深度嵌套的类层次结构。这些类中的数据有两个用途：

• UI 中的渲染
• 求解（即计算负载）

如果我从字面上理解分层架构之类的东西，我会说只需将“Rigging”实现为 POCO，并让渲染（UI 层）和求解（应用程序层）依赖于这些类。

但是，我遇到了两个问题：

• 一方面是渲染和求解，另一方面是构建领域元素的逻辑是由不同的人开发的
• 渲染和求解各自使用数据的不同部分。域类已经相当大，具有构造它们并强制一致性的逻辑。这使得开发类的人很难看出应用程序的其他部分实际上依赖于哪些属性。

我正在考虑以下结构来解决这个问题：

public class Rigging : IRenderableRigging, ISolveableRigging {
   // Logic to construct and keep underlying data consistent, and 
   // transform underlying data into properties used by rendering and solving
}

public interface IRenderableRigging {
   // Properties needed just for rendering, used by GUI 
}

public interface ISolveableRigging {
   // Properties needed just for solving 
}

这是一个好方法，还是一种过于复杂的方法，或者直接违反了依赖关系只能沿着架构层传播的理念？

Answer 1

不知道为什么这个问题被否决了，我认为它有好处。这是我的笔记：

• 在领域层，不允许实现表示/应用层定义的接口。

• 如果 IRenderableRigging 和 ISolveableRigging 不是 Ubiquitous 语言的一部分，则无法在域层中引用或定义它们。领域层的所有元素都必须能够被领域专家和其他利益相关者理解。

• 为了强调 Rigging 封装相干属性的问题，可能存在设计不良的可能性。如果它具有许多可以按其含义进行分组的属性（意味着它们是连贯的并且具有单一职责），则 Rigging 可能由多个值对象组成。值对象使大的聚合根变小。

• 始终在应用程序层使用 DTO 来封装领域模型中您需要的内容。 ISolveableRigging 可能是 SolvingRiggingDto，IRenderableRigging 可能是 RenderingRiggingDto。

• 定义这些接口并不能解决远程开发的通信问题。因为即使在创建接口之后，映射域属性的责任也将成为问题。这些决定必须有意识地做出并在所有团队成员之间共享。您应该考虑敏捷实践并强调团队成员之间的协作。