DDD и Event Driven архитектура [Event Storming, 1]

[@dmitryfokin5205]

Интересно чем отличается "поддомен" от "ограниченного контекста"? Из повествования - получается одно и тоже

[@DeworkerPro]

Мы пытаемся определить единый язык (терминологию) для домена (предметной области бизнеса). Домен делится на поддомены этого домена. Единый язык делится на ограниченные контексты этого языка. Обычно границы совпадают и это воспринимается как одно и то же.

[@dmitryfokin5205]

43:45 если понравится? - а если не понравится твоя схема? могу с точностью 99% сказать, что не понравится. а как новые сотрудники твою схему изучать будут? 80% обывателей не готовы изучать схемы

[@DeworkerPro]

Новым программистам схему после Event Storming отдельно изучать не придётся, так как она один-в-один будет совпадать с программным кодом, где все команды, события, агрегаты и политики будут этими же классами в коде. А других новых сотрудников всё равно придётся как-то обучать. Хоть устно, хоть по письменным инструкциям, хоть по схемам. И вспомогательные инструкции для обывателей можно как раз делать на основе такой модели. А если обыватель вообще не хочет ничего изучать, то ему и никакая другая схема не понравится.

[@dmitryfokin5205]

6:30 ошибка - как программист, так и сотрудники, из практики, не владеют знаниями достаточными для построения модели прикладной области. они не могут разработать рабочую доменную логику. для построения модели нужен методолог, при жтом, если нет отдельного методолога, то его роль должен взять на себя именно программист, т.к. именно он реализует доменную модель в виде программного обеспечения. По этому программисту нужно учить предметные области: и бухгалтерию и CRM и HRM и EMS и кучу других прикладных областей

[@DeworkerPro]

Так суть именно в том, что изначально при создании проекта всеми знаниями не владеет, ни программист, ни другие сотрудники, ни сам заказчик. Владелец не соображает в бухгалтерии, бухгалтер не соображает в маркетинге, программист не разбирается в страховании. У каждого свои знания и свои фантазии. Даже два юриста обычно думают по-разному. Только объединив все знания и догадки вместе получится согласовать и построить рабочую модель. Отдельный менеджер или методолог, разговаривая поодиночке то с заказчиком, то маркетологом, то с юристом, то с программистом, будет каждую идею согласовывать целый месяц. И то не факт, что сам во всём правильно разберётся. Быстрее и удобнее будет собрать всех вместе и согласовать всё сразу.

[@dmitryfokin5205]

@@DeworkerPro Смотри, на сегодняшний день есть два подхода: научный (он же академический, он же инженерный), и идеалистический (он же религиозный). Смысл в том, что методолог, или аналитик ОБЯЗАН владеть предметной областью на уровне учебника ВУЗа. И он реализует достижения науки в прикладной модели, разработанной под особенности заказчика. То, что ты описал - это обывательский подход, ведущий к плоскоземельцам, и в 99 процентах будет построена неправильная модель, в оставшемся 1 проценте 99 процентов будет неправильно реализовано. У разработчика ПО никогда не будет единственного источника правды в который можно тупо ткнуть пальцем, а в инженерном подходе ты покажешь учебник ВУЗа. И поэтому EVENT STORMING не рабочая херь, все только для бессмысленного выкачивания денег. Если ты понимашь инженерный подход, то сразу видишь все волшебные техники - не более чем сектанские пляски с бубном. При этом, например, я в 2001 году вместо очередной книжки по С++ купил самоучитель бухгалтерского учета, а в 2011, понимая отсутсвие знаний предметной области получил второе высшее по управление производственным предприятием. С настуающим Новым годом! Здоровья! Творческих успехов!

[@dmitryfokin5205]

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

[@DeworkerPro]

Так это только первое вступительное видео к большой серии по моделированию. Здесь говорим, что такое событийная архитектура. Во втором эпизоде знакомимся с практикой Event Storming и делаем диаграмму событий для бизнеса международных грузоперевозок. А дальше уже в три этапа делаем модель для нашего проекта аукциона.

[@dmitryfokin5205]

@@DeworkerPro С интересом посмотрю