Какова оптимальная практика совместного использования модели для разных проектов при использовании доменного дизайна? - PullRequest
1 голос
/ 03 ноября 2011

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

В этом случае, как применить проект, управляемый доменом (сначала используйте ORM, модель, генерируя схему базы данных)?Создать несколько баз данных с множеством одинаковых таблиц?Или как поделиться данными?Использовать синонимы?Какова возможная стратегия для разрешения модели совместного использования (включая данные)?

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

Ответы [ 2 ]

1 голос
/ 03 ноября 2011

В моем предыдущем проекте у нас было много дискуссий о наличии избыточной информации в нескольких моделях, имеющих несколько общих частей.

Что нам показалось интересным, так это то, что мы подумали, что несколько проектов (не C # proj, но реальныекрупные проекты разработки), или, как их называют, системы очень редко разделяют одну и ту же точку зрения на использование модели.Мы подумали, что в более крупном домене, охватывающем несколько приложений / систем / проектов, вы можете обнаружить несколько ядер, в которых вы не хотите, чтобы ядра дублировались в каждом приложении.

Все закончилось доменом, который был распределен по нескольким машинам.И у нас были ключи GUID, чтобы связать их вместе в базе данных.Но так как мы делали эту «модель сначала», субдомены выглядели друг на друге как сервисы, связанные с инфраструктурой, которые достигли с помощью событий домена.

Сложно?На самом деле, нет.Вот пример: Домен один (система проверки заработной платы) - У нас есть статистическая система проверки заработной платы, которая проводит оценку заработной платы сотрудников и того, как они соотносятся с их опытом, возрастом и эффективностью.Основой является форма анкеты, оценка работы, ответы на анкету, рейтинг.советы по изменению зарплаты и т. д.

Домен два (система сотрудников) - Здесь вы управляете своим сотрудником, регистрируете новых сотрудников, проводите реабилитацию, возможно, личное развитие, зарплата, контракт с сотрудником, выплаты сотрудникам и т. д.

Домен три (Управление эффективностью) - Здесь вы можете ознакомиться с историей опыта сотрудников, целями, достижениями и соглашениями между руководителем и сотрудниками о личностном развитии, рейтингах и степени эффективности.

Как вы заметили, ядро ​​каждого домена отличается, но у них есть некоторые проблемы.В зависимости от развертывания, инфраструктуры и требований относительно того, насколько тесно они должны быть связаны друг с другом / реагировать друг на друга - технологии, как решить эту проблему, могут различаться.

Я предпочитаю делать эту технологию независимой.Мы использовали NServiceBus для синхронизации домена с помощью событий домена (шаблон событий домена Уди Даана).

Например, как только мы завершим проверку зарплаты сотруднику, начальник должен быть проинформирован о том, что Джо должен получить шанс на повышение зарплаты.с 200 - 500 $ в этом году.

Метод ApplySalaryReview для корневого объекта совокупного объекта не только сохраняет результат проверки, но также вызывает событие домена NotifySalaryReviewSubscribeers, которое запускает обработчик событий HandleNotifySalaryReviewSubscribeersEvent на уровне приложений, который принимает инфраструктуру службы вт е р.Эта служба помещает результат в очередь сообщений, и все системы, которым нужна эта информация, могут подписаться на это сообщение.В нашем случае это Домен два (система Сотрудника).Результат импорта системы сотрудника и уведомление начальника сотрудника о том, что он получил новую информацию о предстоящем разговоре о зарплате с этим конкретным сотрудником.

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

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

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

...