В моем предыдущем проекте у нас было много дискуссий по поводу наличия избыточной информации в нескольких моделях, которые имеют некоторые общие части.
Что нам показалось интересным, так это то, что мы думали, что несколько проектов (не C# proj, а настоящие крупные проекты разработки) или называемые системами очень редко имеют одинаковую точку зрения на использование модели. Мы подумали, что в более крупной области, охватывающей несколько приложений/систем/проектов, вы можете обнаружить несколько ядер, где вы не хотите, чтобы ядра дублировались в каждом приложении.
Все закончилось доменом, который был распределен на несколько машин. И у нас были ключи GUID, чтобы связать их вместе в базе данных. Но поскольку мы сделали эту модель «сначала», поддомены смотрели друг на друга как службы, связанные с инфраструктурой, которые были доступны через события домена.
Сложный? Не совсем. Вот пример: Домен 1 (система обзора заработной платы) – у нас есть статистическая система обзора заработной платы, которая проводит оценку заработной платы сотрудников и того, как они соотносятся с их опытом, возрастом и производительностью. Ядром является форма анкеты, оценка работы, ответы на анкету, рейтинг. советы по изменению заработной платы и т. д.
Второй домен (система сотрудников). Здесь вы управляете своим сотрудником, регистрируете новых сотрудников, занимаетесь реабилитацией, возможно личным развитием, зарплатой, трудовым договором, льготами и т. д.
Третий домен (управление эффективностью). Здесь вы обрабатываете историю опыта сотрудников, цели, достижения и соглашения между начальником и сотрудниками о личном развитии, рейтинге и уровне производительности.
Как вы заметили, ядро каждого домена отличается, но у них есть некоторые общие проблемы. В зависимости от развертывания, инфраструктуры и требований к тому, насколько тесно они должны относиться друг к другу/реагировать друг на друга, технология решения этой проблемы может различаться.
Я предпочитаю делать эту технологию независимой. Мы использовали NServiceBus для синхронизации домена через события домена (шаблон событий домена Уди Дана).
Например, после того, как мы завершили обзор заработной платы для сотрудника и начальника, следует сообщить, что Джо должен получить шанс на повышение заработной платы на 200-500 долларов в этом году.
Метод ApplySalaryReview для корневого агрегата объекта Employee не только сохраняет результат проверки, но также запускает событие домена NotifySalaryReviewSubscribers, которое запускает обработчик событий HandleNotifySalaryReviewSubscribersEvent на уровне приложения, который принимает инфраструктурную службу в ctor. Эта служба помещает результат в очередь сообщений, на которую могут подписаться все системы, которым нужна эта информация. В нашем случае это второй домен (система сотрудников). Система сотрудников импортирует результат и уведомляет начальника сотрудника о том, что он получил новую информацию для предстоящего разговора о зарплате с этим конкретным сотрудником.
Надеюсь, я пролил некоторый свет на один из способов сделать это. Есть и много других способов...
person
Magnus Backeus
schedule
03.11.2011
