业务层模块分离

Question

我们的新项目刚刚开始，但我们遇到了与其架构相关的问题。

我们有一个 3 层架构：

1. 网页界面
2. 商务
3. 数据存储库

每一层都只引用它下面的层。通信是通过我们所说的entities 和business objects (BO) 完成的，如下所示：

DataRepositories <--entities--> Business <--BO--> WebUI

<--X--> 表示使用 X 类型的对象进行通信。

例如，我们将 UserEntity 作为实体，将 User 作为 BO。另一种类型是票证，同样有TicketEntity 和Ticket。

目前，我们在层中有一些不同的垂直切片，例如 Accounts 用于 DataRepositories、Business 和 WebUI 中的用户，这些切片定义明确并且不与 Tickets 等其他切片交互。

现在的问题是，一张票的买家是用户，我们不知道在我们的架构中应该在哪里连接票和用户。业务组件应该在它们之间进行交互还是数据层应该将用户映射到工单？

更具体地说，我们有一个方法用于创建驻留在 Business 中并从 WebUI 调用的工单。它将票证和“用户”的详细信息作为参数，我们还不知道它应该是用户类型的对象还是只是用户名/ID。如果我们传递一个用户对象，那么演示文稿应该在调用 CreateTicket 之前获取用户。但是，如果 webui 传递了 id，那么业务层应该解析用户对象，这需要在门票（业务）中添加对用户业务组件的引用。

Answer 1

就个人而言，我讨厌这样的并行层次结构。您已经创建了您所称的实体，它应该有一些与它们相关联的行为，以及应该是不可变且没有任何行为的业务对象的并行层次结构。

我会放弃业务对象。我怀疑除了不变性和其他人的“架构纯度”概念之外，它们没有提供任何您可以引用的价值。

我也不喜欢实体和存储库之间的箭头方向。我会让存储库知道实体，但不是相反。为什么实体应该知道或关心它是否被持久化？业务逻辑和行为应该保持不变。

我会让视图层与服务交互。这些与 UI 无关，但它们包含您完成用例的所有业务逻辑。如果您丢弃您的用户界面 - 每隔几年就会丢弃一次 - 只要业务问题存在，您的服务就会一直存在。

数据层应对其自身的参照完整性负责。如果一张票需要 JOIN 才能找到它的用户，那么您必须将它放在数据层中。当持久层查询用户时，它还将获取属于该用户的票证并返回对象中的一对一关系。一个用户将有一个列表或一组票实例。所有这些都应该在服务层完成。该服务将协调实现用例所需的持久性、业务对象和其他服务。