我们的新项目刚刚开始，我们遇到了与其架构相关的问题。
我们有一个3层架构：
每个图层仅参考其下方的图层。我们称之为entities和business objects（BO）的内容如下所示：
DataRepositories <--entities--> Business <--BO--> WebUI
<--X-->表示使用X类型的对象进行通信。
因此，我们将UserEntity作为实体，将User作为BO。另一种类型是再次拥有TicketEntity和Ticket的票证。
目前，我们在DataRepositories，Business和WebUI中为用户提供了类似Accounts的层的一些不同的垂直切片，这些用户定义良好且不与Tickets等其他切片交互。< / p>
现在的问题是，票证的买家是用户，我们不知道我们的架构应该在哪里连接票证和用户。业务组件应该在它们之间进行交互，还是数据层应该将用户映射到票证？
更具体地说，我们有一种方法可以创建驻留在Business中的票证，并从WebUI调用。它将故障单和“用户”的详细信息作为参数，如果它应该是user类型的对象或者只是用户名/ id，我们还不知道它们。如果我们传递一个用户对象，演示文稿应该在调用CreateTicket之前获取用户。但是，如果webui传递了id，那么业务层应解析用户对象，这需要在Tickets（Business）中添加对Users业务组件的引用。
答案 0 :(得分：2)
就个人而言，我讨厌像这样的并行层次结构。您已经创建了您正在调用的实体，它们应该具有与之关联的一些行为，以及应该是不可变且没有任何行为的业务对象的并行层次结构。
我放弃了业务对象。我怀疑除了不变性和其他人的“建筑纯度”概念之外，他们没有提供任何你能引用的价值。
我也不喜欢实体和存储库之间箭头的方向。我有存储库知道实体，但不是相反。一个实体为什么要知道或关心它是否持续存在？业务逻辑和行为应保持不变。
我将视图层与服务进行交互。这些是UI不可知的，但它们包含满足用例的所有业务逻辑。如果您丢弃用户界面 - 而且每隔几年就会丢失 - 只要业务问题存在，您的服务就会一直存在。
数据层应该负责自己的参照完整性。如果票证需要JOIN来查找其用户，那么您必须将其置于数据层中。当持久层查询用户时，它还将获取属于该用户的票证并返回对象中的一对一关系。用户将拥有一个或一组故障单实例。所有这些都应该在服务层完成。该服务将编排实现用例所需的持久性，业务对象和其他服务。