领域驱动设计和横切关注点接口定义
Domain Driven Design and cross cutting concern interface definition
我的公司正在尝试采用 DDD。似乎 DDD 的指导是要求域程序集定义其所有服务接口，并允许实现者引用域程序集并实现服务接口。然后使用 DI 域将获得实现。但是，对于横切关注点，要求域程序集重新定义日志记录等不是该程序集核心业务域的接口似乎是不负责任的。我注意到许多商业组件，如 Quartz.NET 正在使用一套标准的、广泛接受的接口，如 Apache Commons，以框架友好的方式解决横切问题。这是否与 DDD 方式一致，或者是否真的像 AOP 一样跳过了圈套，并为横切关注点重新定义了相同的接口，然后使用适配器模式？
供参考：
来自http://www.infoq.com/articles/ddd-in-practice
"These are reusable non-domain related concerns that typically tend to be scattered and duplicated all over the code including the domain layer. Embedding this logic in the domain objects leads to tangling and cluttering of the domain layer with non-domain related code."
来自http://cyrille.martraire.com/2009/12/your-crosscuttingconcerns-are-someone-else-core-domai/
"Your cross-cutting concerns are someone else core domain"
最终取决于您。但考虑到标准确实会发生变化。在我们的行业中，事情并不总是长久存在的，保护自己免受意外和代价高昂的变化通常是一个好主意。你必须在这里做出判断。您是想采用别人的界面并受制于它，还是定义您自己的界面。即使你确实采用了这个接口，你也不会被迫离开它，但实现可能会改变，迫使你在以后编写一个适配器。只要您编写的是接口而不是实现，您就已经过得更好了。
It seems the DDD's guidance is to require the domain assembly
DDD 不需要任何东西。领域层对领域概念和用例进行分组。域本身需要在域级别定义的抽象。我的意思是领域用例需要。日志记录是一个基础设施（技术）方面。通常，此类抽象是公共共享 layer/component 的一部分，可供应用程序的所有部分使用。
Domain 不关心这些东西，DDD 不应被视为食谱，'how to'。这是一种思维方式，应用程序的设计围绕业务概念和用例展开，所有其他技术方面都是实现细节。
"Your cross-cutting concerns are someone else core domain"
这意味着功能对您来说只是一个支持系统，它是其他组件的目的（域）。
我建议您也阅读更多有关 DDD 的内容，并尝试理解这种思维方式并为您的应用采用用例方法。将您的应用程序想象成一组许多专门的迷你应用程序，每个都有自己的关注点，但必须与其他人进行交流。如果您逐个组件构建事物，那么您已经了解 DDD，顺便说一句，您也在实践敏捷。
我的公司正在尝试采用 DDD。似乎 DDD 的指导是要求域程序集定义其所有服务接口，并允许实现者引用域程序集并实现服务接口。然后使用 DI 域将获得实现。但是，对于横切关注点，要求域程序集重新定义日志记录等不是该程序集核心业务域的接口似乎是不负责任的。我注意到许多商业组件，如 Quartz.NET 正在使用一套标准的、广泛接受的接口，如 Apache Commons，以框架友好的方式解决横切问题。这是否与 DDD 方式一致，或者是否真的像 AOP 一样跳过了圈套，并为横切关注点重新定义了相同的接口，然后使用适配器模式？
供参考：
来自http://www.infoq.com/articles/ddd-in-practice
"These are reusable non-domain related concerns that typically tend to be scattered and duplicated all over the code including the domain layer. Embedding this logic in the domain objects leads to tangling and cluttering of the domain layer with non-domain related code."
来自http://cyrille.martraire.com/2009/12/your-crosscuttingconcerns-are-someone-else-core-domai/
"Your cross-cutting concerns are someone else core domain"
最终取决于您。但考虑到标准确实会发生变化。在我们的行业中，事情并不总是长久存在的，保护自己免受意外和代价高昂的变化通常是一个好主意。你必须在这里做出判断。您是想采用别人的界面并受制于它，还是定义您自己的界面。即使你确实采用了这个接口，你也不会被迫离开它，但实现可能会改变，迫使你在以后编写一个适配器。只要您编写的是接口而不是实现，您就已经过得更好了。
It seems the DDD's guidance is to require the domain assembly
DDD 不需要任何东西。领域层对领域概念和用例进行分组。域本身需要在域级别定义的抽象。我的意思是领域用例需要。日志记录是一个基础设施（技术）方面。通常，此类抽象是公共共享 layer/component 的一部分，可供应用程序的所有部分使用。
Domain 不关心这些东西，DDD 不应被视为食谱，'how to'。这是一种思维方式，应用程序的设计围绕业务概念和用例展开，所有其他技术方面都是实现细节。
"Your cross-cutting concerns are someone else core domain"
这意味着功能对您来说只是一个支持系统，它是其他组件的目的（域）。
我建议您也阅读更多有关 DDD 的内容，并尝试理解这种思维方式并为您的应用采用用例方法。将您的应用程序想象成一组许多专门的迷你应用程序，每个都有自己的关注点，但必须与其他人进行交流。如果您逐个组件构建事物，那么您已经了解 DDD，顺便说一句，您也在实践敏捷。