Сущности в ограниченных контекстах в доменном дизайне

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

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

у вас есть сущность сотрудника в контексте 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 SalariedEmployee
{
    public SalariedEmployee(string salaryRef, BankAccount bankAcountDetails)
    {
        ...
    }

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

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

13
bounded-contexts domain-driven-design entity value-type

4 ответов

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

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

теперь должен ли слой сервиса возвращать этот объект value?... Лично я не стал бы этого делать. Я бы предпочел, чтобы эта возможность повторного использования была определена в моих репозиториях. Обмен сопоставлений NHibernate на или делить одну и ту же проекцию класс/маппера.

надеюсь, что это помогает :)

1

от http://msdn.microsoft.com/en-us/library/jj554200.aspx:

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

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

13

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

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

3

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

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

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

2