один модульный компонент должен работать с другими компонентами (компонент = модуль) - PullRequest
2 голосов
/ 05 июля 2011

У меня есть вопрос, но я не уверен, как правильно его описать, поэтому, пожалуйста, внимательно прочитайте.Во-первых, давайте определим термин модуль в моих глазах: module = связка классов, перечисления интерфейсов (и так далее), предназначенные для решения одной задачи.Например:

  • модуль, предназначенный для обработки рабочих договоренностей
  • модуль, предназначенный для ведения бухгалтерского учета

Сегодня наше приложение имеет модуль bookkeepping, предназначенный для управлениявся потребность в bokkeepping в приложении.
У нас также есть ModuleA, который производит элементы, которые впоследствии должны использоваться в модуле bookkeepping для создания из них счетов-фактур.
Итак, чтобы эти два модуля могли контактировать между каждымдругое - мы фактически не рассматривали оба модуля как модули, и каждый модуль знает классы из другого модуля.
Например:

  • В модуле Bookkeepping, если мне нужно загрузить все элементыдля создания счета-фактуры я непосредственно использую класс, отвечающий за элементы из модуля A.
  • Для отслеживания элементов, имеющих счета в модуле А, я сохранил идентификатор счета-фактуры (счет относится к модулю учета) втаблица предметов.

Как видите, существует реальная связьДвенадцать этих двух "модулей".

Теперь у нас есть еще одна потребность.
У нас также есть модуль B, и нам нужно использовать модуль B также с бухгалтерией.Но, как я описал ранее, Bookeeping знает только элементы из модуля A и знает, как взаимодействовать с ними и только с ними.

Как мы можем сделать модуль бухгалтерии достаточно универсальным / модульным, чтобы мы могли использовать и другие модули?с этим?Предположим, мне удается каким-то образом отделить модуль A, модуль B и бухгалтерию, и давайте предположим, что бухгалтерия не знает других модулей.Должен быть кто-то, кто знает все модули для связи между ними!Кто будет связывать модуль B с бухгалтерией?

Я действительно ценю возможные архитектурные решения, схемы и ссылки на соответствующую информацию, которую я должен знать.

Большое спасибо, Наор

1 Ответ

1 голос
/ 05 июля 2011

Если я правильно понимаю вопрос, то я считаю, что проблема, с которой вы сталкиваетесь, связана с концепцией DDD ограниченного контекста .Кажется, у вас есть контекст бухгалтерского учета и другой контекст, который может инициировать события бухгалтерского учета.DDD способ решения этой проблемы заключается в создании отдельной модели для каждого контекста.Например, предположим, что модуль A является контекстом продуктов, он содержит модель домена для продуктов для продажи.В этом контексте существует много аспектов, связанных с продуктами, описаниями продуктов, ценами и т. Д. В частности, продукты в этом контексте являются субъектами .С точки зрения контекста бухгалтерского учета, понятие продукта проявляется как позиция счета-фактуры.Единственными аспектами продукта, которые важны для контекста бухгалтерского учета, являются идентификатор продукта и цена на момент выставления счета.В этом контексте продукты, скорее всего, не являются сущностями по значениям .Поскольку понятие продукта отличается для каждого контекста, следует создать другую модель.Единственное, что сообщается, - это идентификатор продукта, чтобы можно было знать, на какой продукт ссылается контекст бухгалтерии.

Факторинг системы таким образом решает многие другие проблемы, возникающие, когда разрозненные контексты тесно связаны ста же модель.

...