tgoop.com/emacsway_log/1394
Last Update:
Существует модель ментальная (аналитическая) предметной области, грубо говоря, это представление (знания) стейкхолдеров о тех процессах, которые можно автоматизировать информационной системой. Это модель области проблемы (Problem Space), и существует она независимо от того, автоматизирована ли она системой или нет (например, правила рассчета процентной ставки банка, которую высчитывает клерк на калькуляторе). Она является причиной появления автоматизированной системы.
И существует модель решения, т.е. упрощенная интерпретация реальности с целью решения некой проблемы. Это модель области решения (Solution Space), которая подлежит реализации. Это то, что будет "делать" система, business logic (от англ. "business" - "дело").
Эти две модели могут отличаться. Основная идея DDD заключается в том, чтобы они не отличались, т.е. чтобы эти две модели совместить в одну. А поскольку натуральный язык - это средство моделирования, то для достижения этого используется Ubiquitous Language, т.е. использование единых терминов как специалистами области решения (разработчиками), так и специалистами области проблемы (экспертами предметной области). Таким образом, Ubiquitous Language является моделью как области проблемы, так и области решения. В этом заключается основная суть DDD. Такой подход позволяет существенно снизить информационную нагрузку на разработчиков, а значит, снизить вероятность ошибки. Любой, кто знает логику предметной области, легко разберется в том, как устроена система.
Поскольку количество терминов натурального языка ограничено, а количество явлений предметной области безгранично, то языковые конфликты (разные явления под одним термином и, наоборот, разные термины одного явления) являются хорошими признаками границ модели, которые называются Bounded Context.
Основных целей у Bounded Context две:
1. Снизить когнитивную нагрузку, т.е. модель не должна содержать ничего неревантного решаемой ею проблеме, чтобы не создавать паразитную когнитивную нагрузку.
2. Снизить коммуникативную нагрузку, т.е. модель не должна быть разделена между разными командами, которые не смогут и шагу ступить без коммуникаций, не сломав при этом инвариантов модели.
Основная суть EventStorming заключается именно в том, что он позволяет моделировать решение прямо поверх ментальной модели стейкхолдеров, прямо на тех же стикерах. Результатом ES является модель решения, которая в точности отражает структуру будущего кода. Настолько точно, что по этой диаграмме можно делать автоматизированную сверку кода, или даже генерировать сам код (на Java это можно сделать используя сервис от Vaughn Vernon domorobo.to + xoom-designer).
BY emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Share with your friend now:
tgoop.com/emacsway_log/1394