Моя компания пытается внедрить DDD. Похоже, руководство DDD требует, чтобы сборка домена определяла все ее сервисные интерфейсы и позволяла разработчикам брать ссылку на сборку домена и реализовывать сервисные интерфейсы. Затем, используя DI, домен получит реализации. Тем не менее, с точки зрения перекрестных проблем кажется безответственным требовать, чтобы сборка домена переопределяла интерфейсы для таких вещей, как ведение журнала и т. д., которые не являются основной областью деятельности этой сборки. Я заметил, что ряд коммерческих компонентов, таких как Quartz.NET, используют стандартный, общепризнанный набор интерфейсов, таких как Apache Commons, для решения междисциплинарных проблем удобным для фреймворка способом. Соответствует ли это способу DDD или действительно нужно прыгать через обручи, такие как АОП, и переопределять одни и те же интерфейсы для сквозных задач, а затем использовать шаблон адаптера?
Для справки:
Из http://www.infoq.com/articles/ddd-in-practice
«Это многоразовые проблемы, не связанные с доменом, которые обычно имеют тенденцию быть разбросанными и дублироваться по всему коду, включая уровень домена. Встраивание этой логики в объекты домена приводит к запутыванию и загромождению уровня домена кодом, не связанным с доменом».
С http://cyrille.martraire.com/2009/12/your-crosscuttingconcerns-are-someone-else-core-domai/
«Ваши сквозные проблемы являются чьей-то основной сферой деятельности»
