最近我正在努力实现我的 DDD 应用程序的“初始化”逻辑。
我有应该使用特定值初始化的服务，为了更加努力，假设我希望将来在应用程序第一次启动时初始化一些聚合。
如果我在 CQRS 中正确理解 DDD 概念，我可以在每次应用程序启动时发出命令，并且在命令处理程序中，我只会检查事物是否已经初始化，基本上是在注册了一些持久状态时，我会放弃这个命令，就像什么都没发生一样。
最大的问题是我不确定我应该把这种启动/初始化行为放在哪里，它似乎应该驻留在基础设施层。
非常感谢:)
【问题讨论】：
我对Axon的了解还不够，但是问题本身是通用的，下面是通用的解决方案。
您要查找的模式是 Composition Root。
组合根是应用程序中的（最好）唯一位置，模块组合在一起。
它是您的应用程序中发生“对象图组合”的入口点。对象图只是一组对象，它们之间有或没有关系。
通常，在 Java 和 .NET 中，您将使用依赖注入容器来执行此组合。但确切的机制并不重要；它可以使用容器，也可以使用带有中心对象的纯 DI 手动完成。
这样的中心对象将解析/存储配置，根据请求初始化域对象，初始化或存储外部基础设施连接，并且将成为更高初始化机制（如应用程序服务器）的主要入口点。
Composition Root 是一个应用程序基础架构组件。
这意味着只有应用程序才应该有组合根。库和框架不应该。此外，在构建对象图时，组合根通常会引用配置并将正确的外部依赖项注入对象。
compose对象图尽可能靠近应用程序的入口点。
这意味着您的所有应用程序代码仅依赖于构造函数注入或域查找（或其他注入模式），并且永远不会临时组合。只有在应用程序的入口点，才能组合整个对象图。
根据您的应用程序，此入口点可能是：
run 应用服务器提供的方法或启动挂钩（使用 Ruby 和 Python 等语言）IControllerFactory Application.OnStartup 方法ServiceHostFactory
阅读材料：
【讨论】：
我想我个人有一个专用于这个“第一个应用程序启动”的命令。 然后，您将拥有一个命令处理组件，其唯一目的是决定它是否是您的应用程序的第一次启动。
如果是，那么您发出后续命令以启动一些其他操作。 如果不是，您将完全忽略该命令，可能会记录决定反对初始化的日志。 为了推动这个决定，你当然需要在某个地方拥有这种状态。 存储方式/存储位置取决于您，但总的来说，我会声明您应该使用最好的工具来解决问题。例如，一个初始化聚合不会是正确的地方，因为这会引入一些类似于系统聚合的东西。 我宁愿为手头的任务提供一个非常简单的专用查询模型，但鉴于问题上下文，这是我的预感。
最后，我认为将它放入底层就可以了。 它应该是您启动阶段的一部分。之后，如果您愿意，您基本上可以完全放弃此命令处理程序。
这是我的两分钱，希望这有助于@PolishCivil！
【讨论】：