domain-driven-design - 如何在领域驱动设计中使用多态实体进行领域建模？

Question

我正在重建一个会计软件。该软件可以处理多种类型的交易，例如销售、库存补货和费用。我没有会计背景，但我在网上学到了一些概念。我正在尝试根据这些原则对域进行建模:

1. 一个日记账分录由几条记录组成，每条记录要么是借方，要么是贷方。在给定的日记帐分录中，这些记录的借方和贷方总额必须相等(平衡)
2. 必须根据源文档创建日记帐分录。不能无缘无故地简单地创建一个日记条目。

从这些，我得出结论，必须存在这些实体:

1. JournalEntry 实体，它有许多 JournalEntryItem 值对象。该实体负责将其所有条目保持在平衡状态。
2. SourceDocument 实体，其中包含正在进行的交易的一些信息

JournalEntity 和 SourceDocument 都是聚合根，JournalEntity 引用 SourceDocument 身份。

问题来了。作为日记帐分录创建基础的源文档可以是具有不同行为的不同事物。例如，“费用”源单据可能包含一对费用类别和费用金额的列表，而“销售”源单据可能包含相关存货、每个存货的金额以及每个存货的单位价格。

这让我想到了模型中的另一种方法:

1. 创建一个抽象的 SourceDocument 类，具有创建日期和身份属性等共享属性
2. 创建SalesSourceDocument、ExpenseSourceDocument等，它们是从抽象的SourceDocument中扩展而来的
3. JournalEntry 实体仍然必须引用 SourceDocument 身份。

虽然这是有道理的，但我认为这不是在 DDD 中对问题建模的最佳方式，特别是因为它需要有一个抽象实体。

从我在网上看到的有关 DDD 的资料来看，当遇到需要抽象实体的问题时，我需要将其分离到不同的限界上下文中。但是，我不确定它是否可以完成，因为 SourceDocument 标识可能在“销售”上下文中返回具体的 SalesSourceDocument，但它也可能在“费用的上下文。

解决这个问题的最佳方法是什么？

Answer 1

我认为这里要认识到的重要一点是，源文档 术语用于描述期刊条目 和文档 之间的关系，从 JournalEntry 的角度来看。文档是它们自己的 AR，很可能在没有期刊的情况下存在，那么为什么要根据与另一个 AR 的关系来命名它们的抽象？

Source document 很可能是描述与期刊条目相关的文档的必要术语，它很可能也会成为您模型的一部分，但也许在值对象的形式，例如 SourceDocument { id, type }。

这并不意味着如果有用的话，您也不能拥有 Document 抽象:没有理由不惜一切代价避免有用的多态性。

我的分析可能有误(无论如何所有模型都是错误的)，但我只是想为您提供有关特定建模方面的不同观点。

I am rebuilding a software in accounting. This sofware can handle many types of transactions, e.g. sales, inventory restock, and expenses. I have no background in accounting, but I learned some concepts online.

如果您可以在线了解您的整个域，那么它很可能是一个通用的子域，很可能可以在其中购买现成的产品。与其上网尝试自己想出一个模型，不如让领域专家参与进来:也许您的整个愿景在这里都是错误的。

此外，考虑到源文档很可能存在于不同的上下文中，Accounting 上下文似乎可以充当没有明确说明的支持 BC知识或对其他 BC 的依赖。