Контейнеры МОК и доменный управляемый дизайн

На мой взгляд, он прав в том, что не использует контейнер IoC в модели предметной области. Этой практике я следую и сам. Основная идея состоит в том, что сервисы могут содержать зависимости инфраструктуры, и поэтому целесообразно имитировать их. У объектов домена их нет, поэтому не важно их моделировать (все же кодирование интерфейсов - хорошая практика).

Фабрики для сущностей домена не должны находиться в контейнере IoC, но фабрики для сервисов должны. Обычно вы можете ссылаться на фабрики сущностей в своих сервисах. Это не очень тесная связь.

Хорошее чтение об IoC можно найти в сообщении блога Билли Маккафферти «Внедрение зависимостей 101»

Контейнеры IOC неоценимы при разработке кода для модульного тестирования и ортогональны DDD. Вы могли бы создать свою собственную реализацию шаблонов фабрики и компоновщика, если хотите ... зачем испытывать трудности?

Абсолютно. Используйте контейнер IOC, достаточно мощный, чтобы удовлетворить ваши конкретные требования; не больше, не меньше.

Мы используем DDD и внедрение зависимостей (шаблон), но не используем структуру внедрения зависимостей.

Одна проблема с популярными структурами внедрения зависимостей заключается в том, как они разделяют конфигурацию на файлы XML. XML - отличный язык разметки. Как он стал языком конфигурации, я никогда не пойму. Проблема, конечно, в том, что вам нужно запустить приложение, прежде чем вы узнаете, все ли подключено правильно. Также трудно понять, какой код и где используется. Если вы используете интерфейсы, то единственная ссылка на реализацию будет в файле XML, который труднее обнаружить. И, наконец, вы теряете безопасность типов и дженерики. (Однажды я увидел ужасную ошибку в продакшене, которая была бы обнаружена компилятором, если бы мы не использовали XML. )

Я должен отметить, что не говорю, что внедрение зависимостей - это плохо. Это фундаментальный образец хорошего объектного дизайна. Но нет абсолютно ничего плохого в том, чтобы выполнять проводку на фабрике.

В моих последних двух проектах мы удалили большие объемы «кода» из XML-файлов на фабрики. Фабрики связаны с сервисами, управляемыми контейнером (такими как соединения JDBC, соединения JMS и т. Д.). Приложение стало намного проще для понимания, поскольку фабрика менее многословна, чем XML. Программисту на Java гораздо проще связать программу, используя пространство управления, а не тиддлинг XML - и ваша IDE будет выделять, когда вы что-то сломали.

В интеграционном тесте просто создавайте объекты, как вы будет на заводе.

т.е.

dbConnection = DatabaseConnectionFactory.connection();    
serviceUnderTest = new PaymentProcessor(new CustomerRepository(connection));