Контексти та домени, обмежені DDD?

Я працював у відносно складній програмі з 10 таблицями баз даних (агрегати, об'єкти / об'єкти цінності) та застосовував DDD. На даний момент виявляється, що це в основному DDD-Lite, що означає, що існують додатки / доменні служби, модель домену (сутності, об'єкти цінності) та сховища.

Я підняв книгу « Реалізація DDD», і перше, що він згадує, - це DDD-Lite та обмежені контексти та події домену, які відсутні, як перші помилки, які є звичайними при започаткуванні DDD.

В даний час я намагався організувати доменну модель за агрегатними зв’язками та використовувати простори імен, щоб продемонструвати її.

Я не бачу переваг / недоліків, пов'язаних з розділенням проекту «Доменна модель» на окремі обмежені контексти (поки що). Можливо, це стане очевидним пізніше, але я хотів би отримати відгуки в реальному житті про обмежені контексти (і, можливо, піддомени тощо), якщо вони зв'язатимуться з ним.

Розглянемо компанію, яка має кілька різних відділів:

• Розробка програмного забезпечення
• HR
• Бухгалтерський облік

Чи можете ви створити модель користувача, яка може виразно представляти всі ці сфери бізнесу? Подумайте, як може виглядати сутність Користувача у кожному. Можливо, він розділений на три різні сутності:

• Розробник
• Співробітник
• Одержувач платежу

Намагання інстанціювати користувача у кожному контексті значно відрізняється. Можливо, це щось подібне:

• новий працівник (ssn, ім'я, дата приєднання, дата народження, стать)
• новий розробник (працівник, робоча станція, облікові дані)
• новий одержувач платежу (працівник, роль)

Вибачте з прикладу, важко точно проілюструвати без належної доменної моделі для посилання

Якщо ви використовували наївну реалізацію та використовували єдину сутність користувача, це в кінцевому підсумку буде анемічною моделлю даних, повною геттерів та сеттерів, оскільки ви не могли повністю представити користувача у всьому місці.

У бізнесі є чіткі межі, тому корисно моделювати їх таким чином. Користувач, що входить проти користувача в системі оплати праці проти користувача, який грає в гру, всі дуже різні, навіть якщо вони є частиною тієї самої великої системи.

По-іншому - тепер ви можете створити свій код управління розробником, щоб він був дуже легким і незалежним від решти системи. Він може використовувати більш точні типи з меншим багажем. Це крок до створення менших підсистем, які згодом можуть бути видобуті у власній програмі.

Я можу навести вам інший приклад. Подумайте, у вас є система електронної комерції. У вас є продукти, однак продукти будуть частиною принаймні двох різних доменів:

• Каталог товарів, де ви зберігаєте опис товару та всі атрибути
• Інвентар, де у вас запас товару

Якщо у вас є один обмежений контекст для обох доменів, ваше рішення може швидко стати великою кулькою грязі, оскільки ви почнете перехресно посилатися на нього. Зрештою у вас більше не буде двох доменів. Ваш товарний запас буде зіпсований посиланнями на каталог товарів і навпаки. В результаті цього ви не зможете змінити один домен, не торкаючись іншого, навіть ви повністю зрозумієте, що це не потрібно. Ваші моделі стають залежними один від одного і тісно з’єднуються, і погано залежать - залежать від впровадження.

Якщо у вас є два обмежених контексту, всі зміни, які ви робите в одному домені, не вплинуть на інший, як тільки ви очистите свої канали зв'язку. Це означає, що вам потрібно дублювати дані, але це найменші витрати, які потрібно заплатити за програму, що втрачає зв'язані компоненти. Ваші домени можуть спілкуватися один з одним за допомогою подій домену. Навіть якщо ви не плануєте на початку використовувати додаток на основі SOA, ви зможете наблизитись до цього рівня, коли вам потрібно з відносно невеликими зусиллями, оскільки ви просто поміняєте транспорт для подій свого домену, залишаючи ідею позаду.

Оновлення: Є хороший ефір вмінь на SkillsMatter від Еріка Еванса. Він дає аналогію старої історії, коли кілька сліпих людей описують слона з їхньої точки зору. Оскільки кожен чоловік може торкнутися лише частини слона, вони описують його як «дерево», «стіну», «змію», «мотузку». І кожен із цих людей має рацію в своєму контексті. Обмежений контекст - це те, де живе всюдисуща мова. Поза межами контексту ці терміни можуть мати зовсім інше значення, але всередині контексту мова є однаковою у багатьох областях. Грег Янг настійно пропонує почати читати блакитну книгу з глави 11, оскільки там пояснюються найважливіші, фундаментальні поняття. Зосередженість на тактичних зразках на початку книги робить цей підхід "світлом DDD" дуже поширеним,