Объекты в ограниченных контекстах в проекте, управляемом доменами

Я пытаюсь понять, как объекты работают в нескольких ограниченных контекстах.

Предоставлено сотрудником компании. В (например) контексте Human Resources этот человек имеет имя, фамилию, адрес, ссылочный номер зарплаты и банковский счет. Но в контексте учета все, что имеет значение, - это ссылочный номер зарплаты и банковский счет.

У вас есть объект Employee в контексте HR и тип значения (например, SalariedEmployee) в контексте учета?

class Employee
{
    public BankAccount BankAcountDetails { get; set; }
    public string FullName { get; set; }
    public Address ResidentialAddress { get; set; }
    public string SalaryRef { get; set; }
}

SalariedEmployee class (??): Тип значения сотрудника

class SalariedEmployee
{
    public SalariedEmployee(string salaryRef, BankAccount bankAcountDetails)
    {
        ...
    }

    public string SalaryRef { get; }
    public BankAccount BankAcountDetails { get; }
}

Возвращает ли HRService в ограниченном контексте эту информацию? Или вы используете класс Employee в обоих контекстах?

Ответы

Ответ 1

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

Я бы использовал объект value. Трюк состоит в том, чтобы правильно определить объект значения. Я вижу, что они эквивалентны объекту "Типы данных", например целое число. Конечно, это бросает вызов (int16, int32...). Но пусть это так. Является ли Employee хорошим кандидатом для объекта ценности?.... Я так не думаю: (... Вам может не понадобиться такой же набор информации для Employee в ограниченном контексте. В другом имени идентификационная информация сотрудника является лучший кандидат (firstname, lastname, middlename...) Это можно использовать в ограниченном контексте.

Теперь должен ли сервисный слой вернуть этот объект значения?... Personnaly, я бы этого не сделал. Я бы предпочел, чтобы это повторное использование было определено в моих репозиториях. Совместное использование сопоставлений в Nhibernate или совместное использование одного и того же класса проекции/сопоставления.

Надеюсь, что это поможет:)

Ответ 2

Из http://msdn.microsoft.com/en-us/library/jj554200.aspx:

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

Если вы используете шаблон CQRS в ограниченном контексте, вы должны использовать события для этого типа связи: ваш ограниченный контекст может реагировать на события, которые возникают за пределами ограниченного контекста, и ваш ограниченный контекст может публиковать события, к которым могут присоединиться другие ограниченные контексты. События (односторонние, асинхронные сообщения, которые публикуют информацию о чем-то, что уже произошло), позволяют поддерживать свободную связь между вашими ограниченными контекстами.

Ответ 3

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

Если HR создает HRM.Employee, может быть поднято событие, которое учитывает бухгалтерский учет и создает сотрудника Accounting.Employee.

Ответ 4

Если требуется несколько контекстов, определенно некоторые вещи могут быть смоделированы как сущность в некоторых контекстах и объект значения в другом. Перевод с объекта на объект значения обычно прост, но от объекта значения до объекта может быть не так просто. Из Управление доменом, стр. 337

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

Если контекст "Кадровые ресурсы" когда-либо понадобился задавать контексту учета вопрос о конкретном работнике, он стал бы запутанным вопросом.