业务层模块的分离

Question

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

我们有一个3层arhitecture：

1. WebUI中
2. 业务
3. DataRepositories

每一层都有参考，以它下面的层。通信与我们所说的entities和business objects（BO）做如下：

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

<--X-->使用X类型

的对象，所以，我们有例如UserEntity为实体User为BO通信手段。另一种类型是门票，它又有TicketEntity和Ticket。

目前，我们必须通过具有其中明确界定，并不会与其他的片像Tickets互动DataRepositories，商务和WebUI类似Accounts为用户层的一些独特的垂直切片。

现在的问题是，一张票有一个买家是一个用户，我们不知道我们的架构中应该连接票和用户的位置。业务组件是否应该在它们之间进行交互，或者数据层应该将用户映射到票据？

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

Answer 1

就我个人而言，我讨厌这样的平行层次结构。你已经创建了你要调用的实体，这些实体应该有一些与它们相关的行为，还有一个应该是不可变的，没有任何行为的并行层次的业务对象。

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

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

我会让视图层与服务交互。这些是UI不可知的，但它们包含了所有的业务逻辑来满足用例。如果你扔掉你的用户界面 - 而且你将每隔几年 - 只要业务出现问题，你的服务就会一直存在。

数据层应负责其自己的参照完整性。如果票证需要加入以查找其用户，则必须将其存储在数据层中。当持久层为用户查询时，它也将获得属于该用户的票据并返回对象中的一对一关系。用户将拥有一个List或一组Ticket实例。所有这些都应该在服务层完成。该服务将协调执行用例所需的持久性，业务对象和其他服务。