TGViewer
emacsway-log: Technical Leadership, Management, Software Architecture, DDD, Microservices, Distributed Systems, XP, Agile, etc. emacsway-log: Technical Leadership, Management, Software Architecture, DDD, Microservices, Distributed Systems, XP, Agile, etc. @emacsway_log · 3.58K subscribers
Post #1264 3.54K

Forwarded from Ivan

Сложный вопрос. Постараюсь.

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

Существует модель решения, т.е. упрощенная интерпретация реальности с целью решения некой проблемы. Это модель области решения, которая подлежит реализации.

Эти две модели могут отличаться. Основная идея DDD заключается в том, чтобы они не отличались, т.е. чтобы эти две модели совместить в одну. А поскольку натуральный язык - это тоже модель, то для достижения этого используется Ubiquitous Language, т.е. использование единых терминов как специалистами области решения (разработчиками), так и специалистами области проблемы (экспертами предметной области). В этом заключается основная суть DDD.

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

Основных целей у BC две:
1. Снизить когнитивную нагрузку, т.е. модель не должна содержать ничего неревантного решаемой ею проблемы, чтобы не создавать паразитную когнитивную нагрузку.
2. Снизить коммуникативную нагрузку, т.е. модель не должна быть разделена между разными командами, которые не смогут и шагу ступить без коммуникаций, не сломав при этом инвариантов модели.

Основная суть EventStorming заключается именно в том, что он позволяет моделировать решение прямо поверх ментальной модели стейкхолдеров, прямо на тех же стикерах. Результатом ES является модель решения, которая в точности отражает структуру будущего кода. Настолько точно, что по этой диаграмме можно делать автоматизированную сверку кода, или даже генерировать сам код, с помощью инструментов, которые я упоминал ранее (на Java это можно сделать используя сервис от Vaughn Vernon domorobo.to + xoom-designer).
  • 🔥 24
  • 👍 6
  • ❤ 2
More from @emacsway_log
  1. Oct 5, 2026Хочу поделиться книгой, которая хорошо систематизирует скелет знаний: Ведута Н.И. "Экономи…
  2. Oct 3, 2026"Психология конструкторского труда формирует у человека очень важное качество: обязательно…
  3. Oct 3, 2026В последнеё время в пабликах стала актуальной темой о том, как обрести уверенность в услов…
  4. Oct 1, 2026Как не послать человека, но чтобы при этом он хорошо прочувствовал где его место? Мне этот…
  5. Sep 30, 2026В последнее время часто слышу сетование на то, что LLM сделал не то и не так. Давайте посм…
  6. Sep 28, 2026Встретились арх/ит друзьями и знакомыми поговорить про ИИ, архитектуру, про будущее. В общ…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →