隔离域逻辑

在一个设计模式类中，我对建模域逻辑进行了有趣的讨论。 具体来说，它与隔离域逻辑有关 。 应用程序通常分为三个部分：

1. 演示（例如桌面GUI，浏览器，Web服务）
2. 域逻辑
3. 基础架构（例如持久性存储，电子邮件）

该类发现有趣的是，依赖性箭头指向域逻辑部分。 他们问：“该图是否故意弄错了？ 域逻辑部分不应该依赖于持久性存储吗？” 这是一个很大的问题。 我想在这里分享和发布讨论和解释。

经常被误解

大多数开发人员通常都会想到这种误解。

这种误解在很大程度上是由于操作顺序。 它通常以表示层中的触发器（例如，用户单击按钮或链接）开始，然后在域逻辑层中调用某个事物，然后在基础结构层中调用某个事物（例如，更新数据库表记录）。

尽管这是正确的操作顺序，但是域逻辑层的实现方式还是有些微妙的。 这与依赖倒置有关。

依赖倒置原则

域逻辑层可能需要基础结构层提供的某些内容，例如某种从持久性存储中检索的访问形式。 通常的模式是：DAO和存储库。 在这里我不会解释这两种模式。 相反，我要指出的是，接口定义位于域逻辑层中，而其实现则位于另一个单独的层中。

将（DAO和存储库）接口定义放在域逻辑层中意味着它是由域逻辑层定义的。 它决定了需要哪种方法，以及期望哪种返回类型。 这也标志着域逻辑的边界。

接口和实现之间的这种分离可能是微妙的，但很关键。 仅放置接口定义就可以使域逻辑部分不受基础结构细节的影响，并允许对其进行单元测试而无需实际实现。 在单元测试期间，接口可以具有模拟实现。 这种细微的差异在快速验证（开发团队对业务规则的了解）方面有很大的不同。

这种分离是经典的依赖倒置原理 。 域逻辑（高级模块）不应依赖DAO和存储库实现（低级模块）。 两者都应依赖抽象。 域逻辑定义了抽象，而基础结构实现则依赖于这些抽象。

我见过的大多数新手团队都将DAO和存储库接口以及其特定于基础结构的实现放在一起。 例如，假设我们有一个StudentRepository及其特定于JPA的实现StudentJpaRepository 。 我通常会发现新手团队将它们放在相同的程序包中。 这样做很好，因为应用程序仍将成功编译。 但是这种分离已经消失了，领域逻辑也不再分离。

现在，我已经解释了域逻辑部分为何以及如何不依赖于基础结构部分，我想谈一谈表示部分是如何意外地与域逻辑纠缠在一起的。

分开的演讲

我在新手团队中经常看到的另一件事是，他们最终如何将自己的领域逻辑与他们的演示结合在一起。 这导致这种讨厌的循环依赖关系。 这种循环依赖性比物理依赖性更逻辑。 这使得检测和预防变得更加困难。

我不会在这里使用丰富的GUI演示示例，因为Martin Fowler已经在它上面写了一篇很棒的文章 。 相反，我将使用基于Web浏览器的演示作为示例。

大多数基于Web的系统都会使用Web框架进行演示。 这些框架通常实现某种形式的MVC（模型-视图-控制器）。 通常使用的模型直接来自领域逻辑部分。 不幸的是，大多数MVC框架都需要一些有关模型的知识。 在Java世界中，大多数MVC框架都要求模型遵循JavaBean约定。 具体来说，它要求模型具有公共零参数构造函数，getter和setter。 零参数构造函数和设置器用于将参数（来自HTTP POST）自动绑定到模型。 吸气剂用于在视图中渲染模型。

由于演示文稿中使用的MVC框架暗含要求，因此开发人员将向其所有域实体添加公共零参数构造函数，getter和setter。 他们会证明这是必需的。 不幸的是，这妨碍了实现域逻辑。 它与演示文稿纠缠在一起。 更糟糕的是，我发现域实体被发出HTML编码的字符串（例如，带有小于和大于符号HTML编码HTML代码）和XML的代码污染了，这仅仅是因为表现形式。

如果可以将您的域实体实现为JavaBean，则可以直接在演示文稿中使用它。 但是，如果域逻辑变得更加复杂，并且要求域实体失去其JavaBean风格（例如，不再有公共的零参数构造函数，没有更多的设置器），那么建议域逻辑部分实现域逻辑，并通过创建另一个JavaBean对象满足其MVC需求来使表示部分适应。

我经常使用的一个示例是用于验证用户身份的UserAccount 。 在大多数情况下，当用户希望更改密码时，也需要旧密码。 这有助于防止未经授权的密码更改。 下面的代码清楚地显示了这一点。

public class UserAccount {
  ...
  public void changePassword(
      String oldPassword, String newPassword) {…}
}

但这并不遵循JavaBean约定。 而且，如果MVC表示框架无法与changePassword方法配合使用，那么天真的方法将是删除错误的方法并添加setPassword方法（如下所示）。 这削弱了域逻辑的隔离性，并导致团队的其他成员在各处实现它。

public class UserAccount {
  ...
  public void setPassword(String password) {…}
}

对于开发人员而言，理解表示取决于域逻辑很重要。 而并非相反。 如果演示文稿有需求（例如JavaBean约定），则它不应具有域逻辑。 相反，演示文稿应创建具有相应域实体知识的其他类（例如JavaBean）。 但是不幸的是，我仍然看到许多团队仅仅因为表示而迫使他们的域实体看起来像JavaBeans，或者更糟的是，让域实体创建JavaBeans（例如DTO）用于表示目的。

安排提示

这是安排您的应用程序的提示。 将域实体和存储库保存在一个程序包中。 将您的存储库和其他基础结构实现保存在单独的程序包中。 将与演示文稿相关的类放在自己的程序包中。 请注意哪个程序包取决于哪个程序包。 最好将包含域逻辑的包放在所有组件的中心。 其他一切都取决于它。

使用Java时，程序包将如下所示：

• com.acme.myapp.context1.domain.model
  • 将您的域实体，值对象和存储库（仅限接口定义）保留在此处
• com.acme.myapp.context1.infrastructure.persistence.jpa
  • 将基于JPA的存储库和其他与JPA持久性相关的实现放在此处
• com.acme.myapp.context1.infrastructure.persistence.jdbc
  • 将基于JDBC的存储库和其他与JDBC持久性相关的实现放在此处
• com.acme.myapp.context1.presentation.web
  • 将您的Web / MVC演示组件放在此处。

请注意，我使用了context1 ，因为在给定的应用程序（或系统）中可能有多个上下文（或子系统）。 我将在以后的文章中讨论有关具有多个上下文和具有多个模型的信息。

目前为止就这样了。 我希望这个简短的解释可以为那些想知道为什么他们的代码以某种方式排列和拆分的人提供一些启示。

感谢Juno Aliento在这场有趣的讨论中为我的课堂提供了帮助。

节日快乐！

翻译自: https://www.javacodegeeks.com/2017/01/isolating-domain-logic.html