如何根据用例对业务对象建模？

Question

我很难为我的应用程序的业务对象建模。

在我的领域里，我基本上有一个订单清单，对于每一个账单，我有一个托盘，其中包含满足订单的材料。票据是一个复杂的对象，它包含多个属性和一个订单列表，这些顺序反过来又是复杂的对象。托盘对象同样是复杂的，它包含多个属性、堆栈列表和包含堆栈的分布列表；这个列表也包含复杂的对象。

该软件结构为3层应用程序(数据访问层、业务逻辑层和表示层)；表示层遵循MVVM模式，而在DAL层中，我对每个数据模型实体使用一个Repository类。

我的问题是如何定义业务对象。例如，在一个视图中，我必须显示包含详细信息的所有票据列表，指定相关托盘的状态，因此我的类可能是：

相反，在另一种观点中，我必须显示正在处理中的托盘数据和相关票据的一些数据，因此在类中，票据和托盘之间关系的方向应该是相反的：

那么，我应该如何设计我的课程呢？以下是我的一些看法：

• 我可以根据用例使用不同的类对域进行建模，但我不认为是正确的。在我看来，对于一个域，应该只存在一组业务类，所以我必须构建可以用于所有用例的类。
• 我可以在比尔和托盘之间建立一种双向关系，但我认为最好避免这种关系。此外，这个解决方案将迫使我实现某种延迟负载，从而增加了复杂性。
• 我可以删除Bill和Pallet之间的关系，让类更少地耦合到用例，并在视图模型(在表示层)上为特定的用例创建类。本例中的问题是，我应该在表示layer.上移动一些业务规则。

• 我可以删除Bill和Pallet之间的关系，因此让类少耦合到用例，并在BLL上为特定的用例创建类。本例中的问题是，在我的BLL中，我将有非常具体的类，因此它将成为一个不那么通用的层。

Answer 1

如何为业务层建模域类是编写完整书籍的一个主题。这将是过于宽泛的回答，以一般的方式，但这里有几个意见，应该有助于你避免一些常见的陷阱：

• 首先，您需要分离关注点:域不是应用程序。应用程序为其用户提供使用域的功能。有时应用程序完全覆盖域，但有时域在多个应用程序之间共享。此外，如果您将应用程序分解成不同的层，那么它就是要分离不同的关注点，避免业务功能与其他关注点如此紧密地交织在一起(演示、持久性、.)从长远来看是无法维护的。由于所有这些原因，这个领域应该得到充分的理解。
• 需求可以帮助您识别域对象，而不管您是否使用用例或用户故事。用例通常用于系统地标识域实体，使用实体-控制-边界方法。在这方面，你已经确定了很多。
• 您需要根据域中的关系来设计域，独立于当前应用程序将呈现这些关系。一位明智的先锋曾说过：“过早的优化是万恶之源。”
• 需求总是一个很好的机会与用户联系，以挑战您的现实，并澄清他们的期望。例句:一个托盘真的有一张钞票吗？一直都是？也许没关系然后继续。但是，如果你有疑问，首先要澄清，以避免令人痛苦的惊喜。典型的反例:有第一张发票，但由于价格上涨或投诉后给予客户折扣，毕竟还有第二张发票。或者更糟的是，调色板上的一些物品被归还并贷给了客户。
• 领域驱动设计可以真正帮助您在这里使用正确的方法。如果你读了Ewan的书，你就会看到如何根据域的需要来构建关系。
• 域模型显示关联，但很少限制它们的方向，因为它不是域的核心关注点。正如您已经发现的:一个视图可能需要一个方向，而另一个视图则相反。也许几个月后，您就需要在托盘堆栈上开始导航了？你的设计将保持进化论。如果您是在业务应用程序中，与以后实现反向导航相比，只实现单向关联所带来的性能提升是很小的。如果您使用DDD，无论如何，存储库设计将使这种令人担忧的无用:您需要一个托盘？问PalletReportory by id，你需要账单吗？通过BillRepository id问一下。你需要账单上的托盘吗？通过PalletRepository bill_id问一下。