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