Extensibiliy с DDD: модуль с ограниченным контекстом в DDD с MEF

Эрик в своей книге очень мало затрагивает тему Модулей. Он также не говорит о связи структуры модулей с ограниченным контекстом с примерами. Ограниченные контексты содержат модули или модули, содержащие ограниченные контексты? Когда приложение имеет DDD, насколько легко его можно продлить?

Структура приложения очень важна при проектировании расширяемых приложений. Структура Microsoft MEF может автоматически обнаруживать модули/компоненты из dll.

Возьмем пример. В приложении электронной коммерции мы можем иметь ограниченный контекст для Обработки платежей. Обработка платежей может быть абстрактной, поэтому я могу позже расширить приложение с помощью большего количества Платежных Процессоров, таких как Paypal или Payflow. В настоящее время у меня есть только Paypal, и несколько месяцев спустя я хочу интегрировать Payflow. Чтобы интегрировать Payflow, у меня может быть сборка (dll), которая реализует интерфейс Обработка платежей. Я могу отбросить эту DLL в приложении, и MEF автоматически обнаружит ее.

Проблема в том, что DLL, созданная для обработки платежей PayFlow, является модулем, а не ограниченным контекстом (BC). Если я создал его как BC, у нас есть две BC для Обработка платежей. (BC создан для Paypal и BC для Payflow). Если мы структурируем приложение с модулями внутри ограниченного контекста и ограниченного контекста в качестве сборки (dll), модули могут находиться в BC как папки, а не сборки (вы можете думать об этом как о библиотеке С#, созданной в Visual Studio).

Как мы можем справиться с этой проблемой расширяемости с помощью DDD? Является Обработка платежей, BC и разные папки под ним в качестве модулей, один для Paypal и т.д. Или нам нужен суб-BC внутри другого BC?

Ответ 1

Эрик в своей книге очень мало затрагивает тему Модулей. Он также не говорит о соотношении структуры модулей с ограниченные контексты с примерами.

Да, я согласен, что модуль и структура BC не получают достаточного освещения в книге. Я рекомендую Внедрение управляемого доменом проекта Vaughn Vernon для получения более подробной информации.

В ограниченных контекстах содержатся модули или модули, содержащие ограниченные Контексты?

BC содержат модули. Модуль похож на легкий BCs и также принадлежит к вездесущему языку.

Когда приложение имеет DDD, насколько легко его можно продлить?

Это зависит от того, как вы его создаете. Ничто из самого DDD не предотвратило бы расширяемость.

Это обработка платежей, BC и разные папки под ним, как модули, один для Paypal и т.д. Или нам нужен суб-BC внутри другого BC?

Я бы смоделировал каждую интеграцию платежного процессора как модуль в рамках единой платежной обработки BC. Кроме того, каждая интеграция представляет собой ACL между вашей моделью обработки платежей и третьей стороной, такой как PayPal.

Или нам нужен суб-BC внутри другого BC?

Нет, но это затрагивает интересное понятие о суб-БК. Я не думаю, что суб-BC является хорошей идеей, потому что я считаю, что иерархические организации могут быть опасными, что приводит к жестким проектам (например, просмотр ООП с явными иерархиями типов) может быть проблематичным). Вместо этого выберете более плоскую модель с потенциально большим количеством BC. Кроме того, в вашем случае желаемое структурирование может быть достигнуто с помощью модулей.