可扩展领域驱动设计方案的建模

Question

假设我们正在开发一个带有模块(销售、会计、采购等)的应用程序。

这里的一个例子是：

销售模块是可用的基本/主要模块，而会计模块是一个互补模块。

SalesModule
-. Product

和

AccountingModule
-. Account
-. Journal

如果我们这么说：

如果安装了会计模块，那么它将从销售模块提供与Product的直接集成，例如: Product有一个帐户列表，如果将事务应用于Product，将根据该帐户张贴日记。

在我的脑海中，我会想象Product将有一个属性List<Account>，但如果不直接在Product类中添加该属性，那么Product现在就依赖于会计模块，而SalesModule应该能够在没有它的情况下运行。

想到的另一个解决方案是添加SalesIntegrations类(ProductAccount等)，以补充前面描述的Product，使其独立。但这个解决方案听起来并不像a Product has a list of Accounts那样“自然”。

据我所知，做DDD意味着预先了解整个业务规则的概念。

如果需要添加一个新项目来补充以前的DDD项目，而只拥有它的DLL (没有对源代码的访问)，该怎么办？

Answer 1

在Evans的书中，在处理有限的上下文时，您正在经历的问题是有些触及的，这些上下文是与生俱来的分离的(遗留的、不同的团队等等)。并且需要相互作用。

这都取决于投资和资源，但正如您所说的那样，如果您只能访问all，则不能使用任何涉及从其他模块中重构共性的方法，因此您将不得不以类似于处理遗留代码的方式处理它。

您使用的方法在上下文映射策略中进行了描述。在我看来，考虑到无法在现有的代码上工作，像“反腐败层”这样的防御方法可能是这样的。

Answer 2

许多MVC框架利用控制反转注入依赖关系，并使它们更加灵活。不确定您的集成应该有多紧，甚至不确定这些模块应该如何工作。例如：它们都是独立的应用程序吗？

您可能希望了解一些注入依赖项的模式，这是一种具有松散耦合模块的方法。您还可以创建接口来形式化和在模块之间创建“契约”。例如：AccountAwareInterface，有点像setListAccount和getListAccount。

如果产品模块应该工作，而不管其他模块，我将扩展受影响的产品类并在那里集成。但是如何使用一个或另一个类，当然必须正确地配置它。

不确定这是否有帮助。