域驱动设计 - 作为一组 nuget 包实现？

Question

我生活和宣扬 DDD，几乎我开发的每一个项目都以以下形式结束：

- Application Layer
- Business Layer 
- Domain Layer
- Data Layer

这里的每一层都是一组可执行文件或 dll，它们共同构成了应用程序。每个 dll 都以 net48、dotnetcore3.1 和 netstandard2.1 为目标，以实现最大的可重用性。

最近，在一个爱好项目中，我在跨 WPF 应用程序、WebAPI 和一组 Azure Functions 共享组件和定义方面具有可重用性优势。但是现在，我的需求扩展到包括移动（Xamarin）应用程序，所以我想我会将域层移动到一个 nuget 包中，然后将不同的实现引入到不同的应用程序中。这使得重做专门为新的移动应用程序实现的身份验证、日志记录等事情变得很容易，因为域的定义在一个 nuget 包中。

我想知道我的方法是否合理。拥有 nuget 包的好处在一定程度上是好的，但同时，修复小东西或向实体添加属性需要我重新发布和更新版本。单元测试负责逻辑，但我仍然怀念进行良好老式调试的能力。

您对这种方法有何想法和经验？

Answer 1

将域层共享为 NuGet 包（在 DDD 中）正是我们目前正在忙的事情。我说的是一个大型业务解决方案，它有一些“共享”域，然后是特定区域的实现。

共享一个公共域可能是一项艰巨的工作，我建议仅在战略上符合您的业务需求时才采用这种方法。

根据我的经验，我的建议如下：

• 避免大爆炸式方法。不要在第 1 天从共享域开始。您可以从为一个区域/应用程序实施整个域开始。

• 请记住，90% 的相同业务域与完全相同的业务域不同。准备好花费大量时间为您的应用程序设计 10% 不同的域：)

• 识别常用组件。将它们移动到同一解决方案中的单独项目中作为开始。通用组件可能包括通用业务逻辑、基础架构层等。我建议您与您的业务团队一起执行此操作。

• “通用”业务层可能只是聚合、实体、值对象等的一组抽象类。

• 确保您的“通用”代码具有适当的测试覆盖率。

• 避免使用enums。使用Enumeration。与enum 不同，Enumeration 类可以被继承。当您需要在特定实现中扩展 Enumeration 时，这会很有用。

• 除Aggregate 之外的域模型中的方法/行为通常为internal。将方法/行为移动到常见的 NuGet 包时需要小心。将它们设为public 意味着可以从外部修改域模型。您可能需要将它们设为protected，然后让应用程序中的派生类继承域对象。

• 有一次，您对设置感到满意，将公共域项目作为 Nuget 包移动到单独的解决方案中。