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