Домен, управляемый дизайном и определение интерфейса сквозной задачи
Моя компания пытается принять 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/
"Ваши общие интересы - это кто-то другой основной домен"
2 ответа
Кажется, руководство DDD требует, чтобы сборка домена
DDD ничего не требует. Уровень домена группирует понятия домена и варианты использования. Абстракции, определенные на уровне домена, необходимы для самого домена. И я имею в виду необходимые случаи использования домена. Лесозаготовка является инфраструктурным (техническим) аспектом. Обычно такие абстракции являются частью общего общего слоя / компонента и могут использоваться всеми частями приложения.
Домен не заботится об этом, и DDD не следует рассматривать как рецепт, как "как". Это мышление, при котором дизайн приложения вращается вокруг бизнес-концепций и вариантов использования, все остальные технические аспекты - это детали реализации.
"Ваши общие интересы - это кто-то другой основной домен"
Это означает функциональность, которая является просто системой поддержки для вас, это цель (домен) другого компонента.
Я бы посоветовал вам также прочитать больше о DDD и попытаться уловить мышление и использовать подход для вашего приложения. Думайте о своем приложении как о группе из множества специализированных мини-приложений, каждое из которых имеет свои собственные интересы, но должно общаться с другими. Если вы строили вещи компонент за компонентом, то вы понимали DDD и, кстати, вы также практикуете Agile.
В конечном итоге это зависит от вас. Но учтите, что стандарты меняются. Вещи не всегда долго живут в нашей отрасли, и защита от непредвиденных и дорогостоящих изменений, как правило, хорошая идея. Вы должны сделать суждение здесь. Хотите ли вы принять чужой интерфейс и быть признанным за него, или определить свой собственный? Даже если вы примете интерфейс, вы не будете вынуждены переходить от него, но реализации могут измениться, что заставит вас написать адаптер на более позднем этапе. Пока вы кодируете интерфейс, а не реализацию, вам уже лучше.