Предложения по созданию Фабрики для больших доменных объектов - PullRequest
Новая
       29

Предложения по созданию Фабрики для больших доменных объектов

0 голосов
/ 03 января 2011

У нас есть большой граф объектов с множеством свойств и поведения в нем. В настоящее время мы пересматриваем наш домен и собираемся использовать подход DDD. Но мы нуждаемся в предложении ваших экспертов о том, как создать фабрики для нашей модели большого домена.

Проблема

Мы обслуживаем несколько регионов, таких как США, Канада, Испания, Чили, Бразилия, Великобритания и т. Д. Как видно, у каждого из них есть различия в адресах, именах ((фамилия, фамилия 1, фамилия 2 и т. Д.)), номера телефонов, национальные идентификаторы и т. д. На высоком уровне модель домена выглядит следующим образом

  1. Транзакция может иметь несколько Тема
  2. субъект имеет имя, Адрес, Телефонный Номер, Национальный Идентификатор
  3. Субъект может быть ConsumerSubject или BusinessSubject
  4. ConsumerSubject имеет PersonName в то время как BusinessSubject имеет BusinessName
  5. Адрес может быть USAddress, UKAddress, Канадский адрес, Чили адрес и т. Д. и так же может быть география конкретных подклассов для большинство доменных объектов (где применимо)

Для каждого нового запроса нам нужно создать весь этот набор объектов, правильно заполненных в допустимом состоянии. Мы можем использовать шаблон «Абстрактная фабрика», чтобы иметь фабрики, специфичные для географии, такие как USTransactionFactory, CanadianTransactionFactory и т. Д.

Требуется предложение здесь

Как передать параметры для создания этих объектов. Взяв адрес в качестве примера

  1. Если у нас есть метод createXXXAddress (...) для каждая география, которая берет в городе, состояние и т.д. в качестве входных аргументов? This означает, что нам нужно иметь createUSAddress (...), createCanadianAddress (...), createChileanAddress (...) и т. д.

  2. ИЛИ у нас должен быть только один метод createAddress (Address addr) который просто берет объект Address и пусть клиент создаст соответствующая конкретная география Адрес объекта? * 1035 например * SpainAddress spain = новый SpainAddress (); spain.setMuniciplaityName (...);

  3. ИЛИ у нас должна быть отдельная AbstractFactory для каждого из значимых доменных объектов? Например, USAddressFactory, UKAddressFactory и т. Д.

Требуется предложение здесь

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

Любые другие предложения и критика приветствуются.

1 Ответ

2 голосов
/ 03 января 2011
  1. Должен ли у нас быть метод createXXXAddress (...) для каждой географии, которая принимает в качестве входных аргументов город, штат и т. Д.?Это означает, что нам нужно иметь createUSAddress (...), createCanadianAddress (...), createChileanAddress (...) и т. Д.
  2. ИЛИ если у нас есть только один метод createAddress (Address addr), который просто принимает Addressобъект и позволить клиенту создать соответствующий географический объект Address?
  3. ИЛИ У нас должна быть отдельная AbstractFactory для каждого из значимых доменных объектов?Например, USAddressFactory, UKAddressFactory и т. Д.

Я бы определенно не рекомендовал бы вариант 1 : это привело бы к привязке клиентского кода к определенным географическим регионам, вероятно, требующим большого количества switch/ if-else операторы разбросаны повсюду, и код меняется в каждом из них при добавлении / удалении географии - точный полиморфизм проблемы должен был решить .

Я не совсемЯ понимаю, какая разница между вашими вариантами 2 и 3, но мой первый подход заключается в том, чтобы использовать какую-то разновидность GeographyFactory для создания части (частей) или всего графа объектов , который вы здесь описываете.Таким образом, клиенты будут вызывать один createAddress метод, но сам методf будет полиморфным.

Будет ли фабрика зависимостью, введенной непосредственно клиенту или используемой (частично) прозрачно в фоновом режиме, аналогично локали в C ++зависит от обстоятельств - оба подхода могут подойти.

Есть ли необходимость в создании DTO для этого?Я имею в виду просто передать домен на уровень представления, но сохранить неизменяемость, обеспечив просмотр домена только для чтения.

Что касается адресов, я бы попытался уйти только с помощью неизменных объектов - если адрес меняется, вы можете просто создать новый объект и выбросить старый.Обратите внимание, что адреса редко являются первоклассными объектами, а скорее объектами суррогатных значений (т. Е. Не имеют собственной идентичности).Но, конечно, многое зависит от деталей вашего решения объектно-реляционного отображения и схемы БД.

...