Контейнеры IoC и конструкция, управляемая доменом

Я искал руководство для использования контейнеров IoC в проекте, управляемом доменом. Книга Эвана, к сожалению, не затрагивает эту тему. Единственные существенные рекомендации, которые я мог найти в Интернете, здесь.

Многие из пунктов Маловича - здравый смысл, но меня беспокоят некоторые из них. Он предлагает, чтобы контейнер IoC был зарезервирован только для разрешения служб и что использование контейнера IoC для разрешения зависимостей между доменами является плохой идеей. Однако он не подтверждает это утверждение ни с какими примерами. Он просто утверждает это на самом деле.

Далее он говорит, что смешивание контейнеров и фабрик IoC не имеет смысла. Это, похоже, противоречит его первому пункту. Если на самом деле зависимости между доменами не должны быть разрешены контейнером IoC, то как они должны быть разрешены? Книга Эвана четко указывает на то, что фабрики являются логическим выбором.

Я был бы признателен за любой вклад, который у вас есть по этому вопросу. Я новичок, когда дело доходит до DDD и IoC. Я пытаюсь понять, как IoC и DDD могут работать вместе.

Ответ 1

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

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

Хорошее чтение о IoC можно найти на Сообщение блога Билли МакКафферти "Инъекция 101-й зависимости"

Ответ 2

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

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

Ответ 3

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

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

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

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

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

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