使用 .NET 微服务环境变量的领域驱动设计

Question

我正在尝试在 .NET 6 项目中使用领域驱动设计，并且我正在努力解决以下问题。

在我之前的 Big Ball of Mud 项目中，我们通常将应用程序配置变量存储在环境变量（和/或 appsettings.json）中。 我对 DDD 的理解是，我们正在将业务规则/逻辑转移到领域层，以便将其组织到我们的应用层（实现细节）之外。

我完成了关于 Pluralsight 的培训，还回顾了 Microsoft 的面向 DDD 的微服务 (https://learn.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/ddd-oriented-microservice) 和 Clean Architecture。很明显，域层应该引用应用层中的任何内容。 对我来说，使用 appsettings.json 似乎是应用层实现细节的一部分——所以我的问题是，“难道不能将 appsettings.json 与域层一起使用吗？”？

我提出这个问题是因为我想允许使用 appsettings.json 定义某些变量，但是我也希望能够使用这些变量在我的域层中强制实施守卫。

例如，我想在环境变量中定义一个“用户的默认会话长度”，但我也想在创建或更新实体时在域层中强制执行该会话长度。 我知道我可以在应用层中做到这一点，但是将应该绑定到域实体的东西移到应用层中感觉不对。

任何帮助或意见将不胜感激。

Answer 1

概括地说：确定如何处理信息的代码存在于领域层中。确定信息来自何处的代码位于域层之外。

因此，您将拥有域层之外的代码来读取您的环境变量，或读取 appsettings.json 或其他任何内容，并将值作为参数传递给域层。

我能想到至少三种变化

• 领域层定义了一个界面用于访问此实现；应用层实现该接口，并将其实现的引用传递给领域层

• 领域层定义了用于表示此信息的数据结构，并为创建这些数据结构的实例提供了可供性（例如：工厂方法）

• 域层定义了一个接口，该接口以某种通用表示形式（例如：字符串、整数、字节数组等）接受此信息，并隐藏了如何将这些信息组织成数据结构的细节。

Answer 2

我总是喜欢问自己以下问题：

如果用户告诉你他们想用软件做什么，他们真的关心这个吗？在你的例子中，用户的默认会话长度？那是什么东西吗他们提出来的，或者它是一个技术方面的问题您的头脑？

• 如果他们别关心，那么它是技术性的，只是应用层的一部分，而不是领域
• 如果他们做关心，那么它应该是域的一部分。用户的下一个问题是：“需要自己配置吗？“
  • 如果他们说是的，那么会话长度将是聚合的一部分，不会通过设置注入，而是由用户与应用程序交互设置
  • 如果他们说不, 他们很可能有一个特定的默认长度。然后我会在域中明确地对该值进行“硬连线”建模并且不要使其可配置，因为它是一个明确的业务规则并且必须在域代码中相应地表达（可能是需要它的聚合中的常量）。

您可以将这种想法推广到您实现的每个功能。所以自然不需要通过appsettings.json配置域业务规则。或者相反：需要通过设置配置域可能是对 DDD 的误解。

或者你可以这样想：聚合确保业务规则的事务一致性。如果您可以通过appsettings.json 更改值，这对业务规则意味着什么？在没有任何用户交互的情况下，今天对所有聚合实例的一致性定义与昨天不同？这对现有实例意味着什么，它们现在只是无效了吗？在我的耳朵里听起来不像 DDD。