我的公司正在尝试采用 DDD。似乎 DDD 的指导是要求域程序集定义其所有服务接口，并允许实现者对域程序集进行引用并实现服务接口。然后使用 DI 域将获得实现。但是，对于横切关注点，要求域组件重新定义诸如日志记录等不是该组件的核心业务域的接口似乎是不负责任的。我注意到许多商业组件（例如 Quartz.NET）正在使用标准的、广泛接受的接口集（例如 Apache Commons）以框架友好的方式解决横切关注点。这是否与 DDD 方式一致，还是真的有像 AOP 这样的跳跃，
以供参考：
来自http://www.infoq.com/articles/ddd-in-practice
“这些是可重用的非域相关问题，通常倾向于分散和重复包括域层在内的整个代码。在域对象中嵌入此逻辑会导致域层与非域相关代码的纠缠和混乱。”
来自http://cyrille.martraire.com/2009/12/your-crosscuttingconcerns-are-someone-else-core-domai/
“您的横切关注点是其他人的核心领域”
似乎 DDD 的指导是要求域组装
DDD不需要任何东西。领域层对领域概念和用例进行分组。域本身需要在域级别定义的抽象。我的意思是域用例需要。日志记录是一个基础设施（技术）方面。通常，此类抽象是公共共享层/组件的一部分，并且可供应用程序的所有部分使用。
域不关心这些东西，DDD 不应该被视为一个秘诀，一个“如何做”。这是一种思维方式，应用程序的设计围绕业务概念和用例展开，所有其他技术方面都是实现细节。
“您的横切关注点是其他人的核心领域”
这意味着功能只是您的支持系统，它是其他组件的目的（域）。
我建议您也阅读更多有关 DDD 的内容，并尝试了解心态并为您的应用程序采用用例方法。将您的应用程序视为一组许多专门的迷你应用程序，每个应用程序都有自己的关注点，但必须与他人交流。如果您逐个组件地构建事物，那么您已经了解了 DDD，顺便说一下，您也在实践敏捷。
最终取决于你。但考虑到标准确实发生了变化。在我们的行业中，事情并不总是长期存在的，保护自己免受意料之外且代价高昂的变化通常是一个好主意。你必须在这里做出判断。您是想采用别人的界面并对其心存感激，还是定义自己的界面。即使您确实采用了接口，也不会被迫继续使用它，但实现可能会发生变化，迫使您在以后编写适配器。只要您编写的是接口而不是实现，您就已经过得更好了。