广泛中风：决定如何处理信息的代码位于域层内部，而决定信息来源的代码位于域层外部。
因此，域层之外的代码读取环境变量，或读取appsettings.json，或其他内容，值作为参数传递到域层。
我能想到至少三种变体

• 域层定义用于访问该实现的 * 接口 *;应用层实现该接口，并将对该接口实现的引用传递给域层
• 域层定义了用于表示此信息的数据结构，并提供了用于创建这些数据结构的示例的启示（例如：工厂方法）
• 域层定义了一个接口，该接口以某种通用表示形式接受此信息（例如：字符串、整型、字节数组等），并隐藏了这些信息如何组织成数据结构的细节。

我总是喜欢问自己以下几个问题：
如果用户告诉你他们想用这个软件做什么，他们真的关心这个事情吗？在你的例子中，* 用户的默认会话长度 *？这是他们提出来的，还是你头脑中产生的技术问题？

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

您可以将这种思想推广到您实现的每个特性中，因此自然不需要通过appsettings.json配置域业务规则，反之亦然：需要通过设置来配置域可能是对DDD的误解。
或者你可以这样想：Aggregate确保业务规则的事务一致性。如果您可以通过appsettings.json更改值，这对业务规则意味着什么？在没有任何用户交互的情况下，今天对所有Aggregate示例的一致性定义与昨天不同？这对现有示例意味着什么，它们现在只是无效吗？在我听来不像DDD。