Дизайн, керований доменом, - це методологія та рецептурний процес для розробки складних систем, у центрі уваги яких - відображення діяльності, завдань, подій та даних у проблемній галузі в технологічні артефакти домену рішення.
Основна увага Дизайну, керованого доменом, - розуміння проблемної області для створення абстрактної моделі проблемної області, яка потім може бути реалізована в певному наборі технологій. Дизайн, керований доменом, дає методичні рекомендації щодо того, як розробка цієї моделі та розвиток технологій може призвести до створення системи, яка відповідає потребам людей, які її використовують, а також є надійною в умовах змін у проблемній галузі.
Сторона процесу дизайну, керованого доменом, передбачає співпрацю між експертами домену, людьми, які знають проблемну область, та експертами з дизайну / архітектури, людьми, які знають домен рішення. Ідея полягає у створенні спільної моделі із спільною мовою, щоб люди з цих двох різних областей із двома різними перспективами обговорювали рішення, вони насправді обговорюють спільну базу знань із спільними поняттями.
Відсутність спільного розуміння проблемної сфери між людьми, які потребують певної системи, та людьми, які розробляють та впроваджують систему, здається, є основною перешкодою для успішних проектів. Дизайн, керований доменом, - це методологія вирішення цієї проблеми.
Це більше, ніж мати об’єктну модель. Основна увага приділяється спільному спілкуванню та вдосконаленню співпраці, щоб можна було виявити актуальні потреби в проблемній галузі та створити відповідне рішення для їх задоволення.
Дизайн, керований доменом: добро та виклик пропонує короткий огляд цього коментаря:
DDD допомагає виявити архітектуру верхнього рівня та інформує про механіку та динаміку домену, який програмному забезпеченню потрібно копіювати. Конкретно, це означає, що добре проведений аналіз DDD мінімізує непорозуміння між експертами домену та архітекторами програмного забезпечення, і це зменшує кількість подальших дорогих запитів на зміни. Розбиваючи складність домену на менші контексти, DDD уникає змушення архітекторів проектів проектувати роздуту об'єктну модель, де втрачається багато часу на опрацювання деталей реалізації - частково тому, що кількість організацій, з якими потрібно мати справу, часто зростає поза розмір білих дощок для конференц-залів.
Також дивіться цю статтю Дизайн, керований доменом для архітектури служб, який дає короткий приклад У статті подано наступний мініатюрний опис дизайну, керованого доменом.
Дизайн, керований доменом, виступає за моделювання на основі реальності бізнесу, що стосується наших випадків використання. Оскільки зараз старіння та рівень шуму зменшуються, багато хто з нас забувають, що підхід DDD дійсно допомагає зрозуміти існуючу проблему та розробити програмне забезпечення для спільного розуміння рішення. Під час створення програм DDD розповідає про проблеми як домени, так і субдомени. Він описує незалежні кроки / області проблем як обмежений контекст, підкреслює загальну мову для розмови про ці проблеми та додає багато технічних концепцій, наприклад, сутності, ціннісні об’єкти та сукупні кореневі правила для підтримки реалізації.
Мартін Фаулер написав ряд статей, в яких згадується дизайн, керований доменом як методологія. Наприклад, ця стаття, BoundedContext , пропонує огляд обмеженої концепції контексту від доменної розробки.
У ті молодші дні нам рекомендували побудувати єдину модель всього бізнесу, але DDD визнає, що ми дізналися, що "повне об'єднання доменної моделі для великої системи не буде здійсненим чи економічно ефективним" 1 . Отже, натомість DDD розбиває велику систему на обмежені контексти, кожен з яких може мати єдину модель - по суті спосіб структурування MultipleCanonicalModels.