Проектирование на основе доменов: обработка сложных объектов со многими состояниями и отношениями (Недвижимость) - PullRequest
9 голосов
/ 29 ноября 2010

Итак, я довольно новичок в DDD и пытаюсь создать масштабируемую и гибкую систему для моего текущего работодателя (Агентство недвижимости), которая поможет нам ускорить внутренние процедуры компании.

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

Например: в сфере недвижимости «Консультант по недвижимости» посетит дом потенциального «Клиента» и предоставит «Оценку» его'Имущество'.При перечислении эта «Оценка» становится «Листингом», который также может стать «Проданным имуществом» или «Изъятым имуществом».Существует так много разных состояний, в которых может быть «собственность».Должен ли я определять «Свойство» как сущность или каждое отдельное состояние (Оценка, Распечатка, Продано, Снято) должно быть определено как отдельная сущность?

Хотя проблема становится более сложной, когда мы добавляем «Клиенты»'в смесь.Клиент может быть «Владельцем недвижимости», «Покупателем», «Покупателем», «Теннантом», «Инвестором», «Застройщиком» и многими другими.Кроме того, клиент может быть комбинацией более чем одного из них!Опять же, должен ли «Клиент» быть сущностью, и все эти состояния должны быть представлены просто как свойства сущности «Клиента» или они должны быть отдельными сущностями?

Кроме того, как насчет отношений «Клиента»?юридические лица в собственностьЭто отношения многие ко многим, и я не вижу простого способа их объединить.DDD, похоже, заявляет, что сущность должна быть уникальной в своем существовании, следовательно, это означает, что у меня не может быть сущности «Свойство» со списком присоединенных сущностей «Клиент», не заставляя мою сущность «Клиент» вести себя как ВО.И наоборот, при рассмотрении сущностей «Клиент» со списком связанных с ними сущностей «Недвижимость».

Последние 2 недели я читал по этой теме 8 часов в день.Это очень запутанно, и мне еще предстоит распутать беспорядок.Любая помощь и указатели в правильном направлении будут с благодарностью!

Ответы [ 3 ]

4 голосов
/ 30 ноября 2010

Я не занимаюсь PHP, но могу предложить, как моделировать ваши классы:


Клиенты и роли

  1. Создать интерфейс (или реферат класс) называется Роль . Роль имеет ссылка на клиента

  2. Унаследовать следующие классы от Роль: Владелец , Покупатель , Покупатель , Tennant , Инвестор

  3. Для каждого из этих конкретных классов ролей, расширить членов по мере необходимости (например, Теннант может иметь Ежемесячная арендная плата )

  4. Добавьте список ролей вашему клиенту. Всякий раз, когда новая роль добавляется в Client.Roles , роль должна ссылка на клиента

Важная часть: Большинство ваших классов должны ссылаться на отдельный Роль объект, а не на Клиента. Вы можете получить доступ к клиенту через роль.


Состояния собственности и переходы

  1. Создайте интерфейс (или абстрактный класс) с именем PropertyEvent . Добавьте к нему свойство отметки времени с именем OccurnAt .

  2. Унаследовать от PropertyEvent следующие классы: Оценка , Листинг , Продано , Снято

  3. Для каждого из этих конкретных классов PropertyEvent необходимо расширять членов по мере необходимости (например, Оценка будет иметь связанный AppraisedBy ?)

  4. Добавьте список PropertyEvents к вашему Имущество. Всякий раз, когда состояние меняется, создать соответствующее событие и добавить это Пропорги. История .

Важная часть : Это понятие Событие домена . Этот метод автоматически предоставляет историю изменений состояния объекта.


Обратите внимание, что я не фокусировался на объектах, или агрегатах, или объектах значений. Вы можете решить это, когда будете лучше чувствовать свою модель.

Надеюсь, это поможет!

2 голосов
/ 29 ноября 2010

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

Для идентифицированных вами сущностей, которые имеют различные «состояния», изучите Шаблон проектирования состояний - с учетом того, что в вашей ситуации сущность может иметь более одного состояния. Определите, какие объекты являются Агрегированными Корнями - звучит как Собственность и Клиент - и из-за сложных отношений рассматривайте каждую в отдельном Ограниченном Контексте. Тогда я думаю, что ваш инстинкт верен, передайте аутсайдера как объект-значение в ограниченный контекст другого, чтобы получить результаты (скорее всего, через объект-сервис).

1 голос
/ 29 ноября 2010

Для клиентов рассмотрите возможность предоставления им ролей. Роли могут быть отдельными объектами, и у объекта Client может быть много таких ролей.

...