Нужны ли архитектору нотации или квадратики со стрелочками как искусство

Великий сыщик Шерлок Холмс считал важным не забивать голову лишней информацией. Помнится, узнав что Земля вращается вокруг Солнца, он пожелал поскорее про это забыть, как бесполезное в его жизни знание.

Иногда встречаю похожее отношение к формальным нотациям, дескать нах.. зачем мне вникать в эти ваши UML/ArchiMate/BPMN, большинство стейкхолдеров впадают в ступор при виде "правильных" диаграмм, а все обсуждения происходят вокруг рисунков на салфетках с квадратиками и стрелочками. Может и правда, строгие нотации - это излишнее, устаревшее, древнее го.. знание, которое нужно как можно скорее забыть и более не вспоминать?

Но вот мне так вааще не кажется. Нотации - это же не просто способ рисования, это способ структурировать и упорядочить мышление. Самое главное, как по мне, это не то как оно изображается, важно что именно изображается. Нотации содержат ценное знание о том, какие аспекты системы важно выделять, какие отношения вообще бывают между компонентами. Они задают язык, на котором мы думаем и потом разговариваем.

Рисуя "квадратики со стрелочками" на салфетке, архитектор осознанно упрощает сложную модель, которая живет у него в голове (или, может быть она даже выражена где-то в формальной диаграмме), и целенаправленно выбирает те элементы модели, которые важны для конкретного разговора. Но чтобы создавать сложную модель - неплохо бы иметь в голове язык для её создания. Можно, конечно, придумать свой язык, а потом обижаться и расстраиваться, что его никто не понимает, а можно использовать уже кем-то выстраданные, вымученные и вылизанные абстракции. Нотаций много, выбирай на вкус подходящую к конкретной задаче.

Картинка к предыдущему посту - рисунок Фредерика Фореста. Она предельно проста и лаконична. Но почему-то у меня не возникает сомнений, что для того, чтобы добиться этой простоты, лаконичности и выразительности, он довольно долго изучал и анатомию, и законы перспективы, ну и всё остальное, что там еще художники изучают.

Так что не игнорируйте нотации. Не обязательно им прямо строго следовать в каждой схеме, но важно, чтобы всегда могли объяснить, а что же именно кроется за обозначениями. А в идеале, чтобы и объяснять ничего не надо было, а "наброски на салфетке" были столь же точными и выразительными, как этот рисунок.

Я сейчас активно применяю AI в PDLC, так как канал архитектурный, поделюсь наблюдениями в части архитектуры на основе проектов с клиентами.

1. Мусор на входе - мусор на выходе. AI анализирует данные и здесь очень большая проблема. Сейчас же только ленивый не идет в AI и с чем сталкивается сразу на входе? Либо данных нет, либо они в ужасном состоянии, либо они с огромными пробелами, разбросаны, в итоге мы получаем фрагментированный и непригодный контекст. Если раньше можно было отложить на второй план управление тех долгом, не уделять должного внимания документации, то теперь, если вы хотите получить преимущество от использования AI, придется эти долги отдавать, иначе он выдает какую-то глупость. А отдать этого долг AI никак не помогает, у него просто нет входной иформации. И вот мы начинаем проводить event storming, архитектурые воркшопы, архитектурную базу знаний (структуру документации), чтобы ее можно было начать использовать с AI и только после этого (не совсем только) получить значительный эффект.
2. Для архитектуры очень важен бизнес-контекст, а он обычно тоже слабо описан. Структурированное описание бизнес-требований, с метриками и бизнес-архитектурой тоже становятся достаточно важными. Еще очень важным становится качественный discovery-цикл. AI может прекрасно обрабатывать со всех сторон результаты интервью клиентов, но если интервью проведено плохо – ничего не поможет, поэтому навык проведения интервью (а тут уже AI особо не поможет) тоже достаточно важен. Опрос AI в некоторой роли тоже не сильно помогает, потому что у каждой компании свой контекст, который публично не транслируется за пределы компании того, с кем проводите интервью.
3. Все-таки AI в ближайшее время на заменит архитектора, политику никто не отменял. Он даст гипотезы, подсказки, кучу материалов, но окончательное решение, валидация и ответственность будет все равно за архитектором, поэтому развитие архитектурных скилов критически важно (да, и навык критисеского мышления становится еще более важным, потому что AI порой выдает очень уверенно и обоснованно чепуху). Сильного архитектора, если у него в материалах порядок и у бизнеса в материалах порядок AI действительно очень сильно усиливает, проверено.

В общем, очень похоже на микросервисы. Микросервисы - это архитектурный стиль, один из многих. Чтобы спроектировать хорошее микросервисное решение, нужно хорошо понимать фундамент архитектуры, проектирования распределенных систем и DevOps и микросервисы тогда становятся всего лишь одним из стилей в арсеналей архитектора. С AI выглядит точно так же. Так что потребность в базе никуда не делась, а, видимо, стала даже более важной, иначе мы рискуем получить тысячи нерабочих решений и экспоненциальный рост техдолга.

Сегодня заканчивается подача заявок на осеннюю конференцию Flow в Питере

Если кто хотел выступить — самое время вписаться: https://flowconf.ru/callforpapers/

Моя тема:

Пошаговая технология проектирования архитектуры. Срываем покровы таинственности с самой непонятной и мутной дисциплины в современном ИТ.

Аннотация
Как начинать проектировать архитектуру как инженер, а не профан? Где взять целостный подход, если вокруг лишь фрагменты общей картины — DDD, атрибуты качества, интеграционные шаблоны, event storming, модели C4?

В этом докладе я расскажу о полной технологии проектирования архитектуры, которую мы разработали вместе с ноосферой в лице OpenAI (в основном книги издательства O'Reilly) и отточили с архитекторами информационных систем. Эта технология описана в открытой методичке и охватывает всё: от стратегических целей бизнеса до физической архитектуры.

В отличие от разрозненных методов, я собрал воедино:
- подходы от DDD до Attribute-Driven Design;
- чек-листы, шаблоны и таблицы, одобренные архитекторами;
- релевантные кейсы из сферы FinTech, ритейла и госсектора.

Этот доклад — приглашение в архитектуру как в процесс, в котором опытный ИТ-специалист может наконец выступить не просто наблюдателем игр демиургов, а активным деятелем, равноправным участником. Расскажу, с чего начать, как не утонуть в деталях и частностях и какие шаги ведут к обоснованной и устойчивой архитектуре.

Целевая аудитория
- опытные системные аналитики и разработчики, которые всё чаще сталкиваются с архитектурными задачами и хотят понимать, как проектировать архитектуру от и до, а не обрывками;
- руководители отделов анализа, проектирования и архитектуры, стремящиеся расширить архитектурную экспертность в команде;
- ИТ-преподаватели, авторы учебных курсов и руководители ИТ-школ, которым нужно разобраться, чему именно учить в сфере проектирования архитектуры.

С чем уйдут участники доклада
- с пониманием, какие шаги включает проектирование архитектуры согласно современным методикам;
- с готовыми шаблонами и чек-листами, которые можно использовать уже завтра;
- с инструментом, который помогает идти по предложенной технологии и создавать качественные артефакты в ходе проектирования в рабочем контексте;
- с ощущением, что архитектурное проектирование — это не сакральные знания, а устойчивая и постижимая за конечное время технология деятельности.

Погружение в Лейкхаус! Офигенная новость, ребят – качаем, наконец, DWH! В следующую среду 13-го августа в 18:30 msk в Zoom состоится встреча с Алексеем Белозерским, руководителем группы BigData Services VK Cloud.

Тема встречи “Погружение в Лейкхаус: почему все о нём говорят”.

Обсудим:
- Ретроспектива развития хранилищ данных. Принципы и компоненты. Озера vs DWH. ETL vs event streaming. Витрины. Базовые классы компонент: базы и подтипы, распределенные хранилища, стриминг и процессинг, in-memory grids. HDFS/Hadoop, Spark, колоночные базы (Clickhouse, Vertica etc), Greenplum/Greengage, Exasol, Snowflake и тд и трансформация в современный стэк, Trino/Iceberg/S3 или in-memory processing, аналитические embedded-базы типа DuckDB
- Тренды, разделение compute/storage, in-memory вычисления. Почему сейчас старые методы не едут. Какие требования от современного бизнеса и почему старые ХД не удовлетворяют им: рост объемов, рост аналитической нагрузки, требования регуляторов в разных странах.
- Как это все расшивается на "новом" стеке из Лейкхауса - и почему об этом все говорят.

Встреча состоится в Zoom, в этот раз она свободна и для сообщества Devhands Club (слушатели наших курсов) и для всех остальных желающих принять участие в живой дискуссии, но обязательно нужно быть авторизованным в Zoom.

Topic: Devhands Open Sessions: Lakehouse deep-dive (A. Belozersky)
Time: Aug 13, 2025 06:30 PM Istanbul/MSK
Zoom: https://us06web.zoom.us/j/85409552470?pwd=mfmnt6aRvmllJB1iLx8Ws4sdiIqVD3.1
Добарить в календарь: https://addcal.io/e/k0dw9sgjk8ai

Приходите, приводите друзей!

Не так давно я писал, что что нотации - это не просто способ рисовать квадратики со стрелочками, а в первую очередь - инструмент структурирования мышления аналитика или архитектора. Сегодня хочу показать это на конкретном примере — нотации EPC (Event-driven Process Chain).

Суть нотации EPC удивительно проста: мир состоит из событий (состояний) и функций (действий). События запускают функции, функции порождают новые события. Вокруг функций крутятся информационные сущности, являющиеся входными или выходными данными функций, а также ресурсы, необходимые для их работы (например, сервис-исполнитель функции). И всё, больше почти ничего не нужно для описания любого процесса.

При попытке описать автоматизируемый процесс терминах EPC невольно задаёшься вопросами:
- Какие события случаются в процессе или в каких состояниях бывают объекты, задействованные в процессе?
- Какие действия переводят объекты из одного состояния в другое?
- Кто или что выполняет эти действия?
- Какая информация и какие ресурсы нужны для выполнения действий?

Можно провести определенные параллели этой нотации с концепцией Event Storming. Оранжевые стикеры событий и синие стикеры команд в Event Storming — это почти те же события и функции из EPC, только в более неформальном виде. Но есть нюанс, в Event Storming подразумевается, что событие триггерит команду (т.е. событие достаточно для запуска команды), а в EPC связь между событием и функцией означает, что функция может исполняться только после наступления определенного события, т.е. событие/состояние необходимо для функции, но недостаточно. EPC дополнительно уделяет внимание информационным потокам, исполнителям и другим ресурсам, необходимым для работы функций.

В свое время эта нотация очень помогла мне осознать и структурировать процесс конфигурирования IDM системы. Наша система имела большое количество взаимосвязанных конфигурационных параметров и настроек. Технически все было не очень сложно, но из-за их количества и разбросанности по элементам конфигурации было очень сложно понять и объяснить другим с чего и как нужно начинать настройку, какие опции на какие аспекты поведения влияют.

И я начал просто выписывать процесс настройки по шагам: вот, настраиваю вот это (элемент-действие, например, настройка подключения к Active Directory), использую для этого вот такие элементы конфигурации (информационный объект - параметры конфигурации подключенной информационной системы), получаю в результате событие (например, подключена AD). Событие описывает новое состояние системы, в котором я получаю возможность переходить к следующим действиям - настройками других элементов.

Так постепенно я задействовал все элементы конфигурации в разных процессах конфигурирования и увязал процессы конфигурирования в цепочку через события. Дальше аналогичным образом описал использование элементов конфигурации в процессе функционирования системы как исполнителя действий с учетными записями в ответ события жизненного цикла сотрудника компании, от приёма на работу до увольнения.

Эти две диаграммы позволили четко увязать между собой элементы конфигурации, шаги процесса конфигурирования и собственно функции IDM - что и зачем нужно настроить для того, чтобы корректно работали определенные функции процесса управления учетными данными.

Не скажу, что я супер строго следовал нотации, когда рисовал эти модели. Как я уже говорил, важна не сама нотация, важна картина мира, которая создается с её помощью, аспекты, которые нотация подсвечивает и делает явными.

Именно про это ключевой тезис этого поста: нотация EPC - очень полезный инструмент для анализа процессов с целью выявления и структурированного документирования событий и промежуточных состояний самых разных систем, действий, приводящих к этим событиям и состояниям, ну и нужных для этого ресурсов.

Геннадий высказался очень созвучно моим мыслям. Просто продублирую его пост.

Сейчас в моду вошло философское течение, осмысляющее роль архитектора.

Выскажусь и я, раз уж всё равно толком ничего не успеваю.

Я отношусь к числу радикалов, считающих, что архитектура — это фикция. И рассматривать роль архитектора стоит через призму роли самой архитектуры.

Разложу по слоям:

- Бизнес-архитектура — это вовсе не архитектура, но при этом крайне важная штука.
- Корпоративная архитектура — это де-факто учет, секретариат при службе завхоза (офиса CTO).
- Архитектура приложений — это чистая инженерия, программная инженерия.
- Архитектура решений - это пересечение множества элементов структуры того, что назвается бизнес-архитектурой и множества элементов структуры приложений

Если напрямую связать, в том числе инструментально, то, что называют бизнес-архитектурой, с инженерией, то учетную функцию можно полностью автоматизировать.

А всё, чем я занимался за свою карьеру в должностях со словом «архитектор» в названии, — это либо чистая инженерия, либо сопряжение чего-то важного со стороны бизнеса с чем-то важным со стороны инженерии. И да, без такого сопряжения никакой инженерии и не бывает.

Свежие вести с полей!

В Obsidian-е подвезли новый core plugin - Bases (см. https://help.obsidian.md/bases)!
По сути - встроенный аналог плагина DataView.
С функциональной точки - послабже будет, чем DataView, в частности, не умеет выводить список задач. Впрочем, я думаю, что это только пока. А вот с точки зрения usability - довольно мощная штука.

Итак, к сути. Данный плагин, несмотря на громкое название Bases, представляет собой встроенный механизм запросов, фильтров к заметкам, а также представлений результатов, причем описания этих самых фильтров и представлений сохраняются в заметке в виде блока неформатированного текста.

``` base
filters:
  and:
    - file.mtime >= now() - "3d"
views:
  - type: table
    name: Table
...

```

Плагин интерпретирует фильтры и умеет показывать результаты в виде таблички или набора карточек. Но главная фишка, что делать редактировать это описание не обязательно только руками. Есть довольно удобный UI для его редактирования.

П

(сработало ограничение на размер текста под картинкой)
UI для редактирования - это сильное преимущество core:Bases по сравнению с community:DataView. Там много прикольных фишечек, сильно снижает порог входа для начала использования плагина.
Отдельная прикольная плюшка - возможность редактирования (!) заметок по месту, прямо в табличке с результатами поиска - редактировать свойства заметок, проставлять теги.

Итог - выглядит красиво, наверное полезно будет для всяких каталожных, справочных наборов заметок. Но для себя сходу применения не увидел...

Почему так?
У меня основная масса заметок - это попытка размотать разрозненные мысли в какие-то структуры - списки, структуры, тексты с отбивками, т.е. большое и непонятное разбивается на связанные каким-то образом части. И все эти части оказываются в одной заметке. Мне было бы интересно иметь возможность поиска, фильтров и редактирования не только заметок, но и отдельных элементов (строк в списках, абзацев, задач) в составе заметок. Тогда, наверное, я бы перетащил сюда управление проектами и задачами, попробовал бы организовать управление знаниями на основе разных классификаторов.

Роли - одно из самых базовых и одновременно одно из самых трудно понимаемых понятий системного мышления. На днях у меня случайно оформилась одна аналогия, которая, как мне кажется, может помочь освоение этого понятия тем, кто в школе хорошо учил физику.

Системное мышление учит, что не стоит рассматривать человеков вокруг как сложных, непонятных личностей со своими внутренними установками и переживаниями. Ну, т.е. это тоже можно делать, это прикольно, но не очень полезно в деятельности. Вместо этого предлагается сделать умственное усилие и каждого человека виртуально декомпозировать в набор ролей, которые он "играет" в интересующей нас части мира, а дальше анализировать интересы и поведение именно этих ролей. Роль - это некоторый изолированно рассматриваемый аспект поведения человека, некоторая целенаправленная, логически выделенная, целостная часть общего поведения. Подробнее про как и зачем это всё читайте в учебниках по СМ, формат тележки не очень предназначен для такого рода материалов.

Так вот, опыт показывает, что перейти к такого рода восприятию ОЧЕНЬ сложно, умственное упражнение кажется очень искусственным и нелогичным. Как можно нарезать настоящую сложную личностную целостность человека на какие-то сухие, скучные, искусственные роли? Ну глупость же..

А на днях, решая с сыном школьную задачу, я вдруг осознал, что в физике применяется очень похожий приём. Помните школьные задачи? На столе лежит брусок со скошенным краем, на нем кирпич, а сверху на нити, пропущенной через систему блоков, спускается металлический шарик. Ну да, я немножко утрирую :). В условиях задачи мы видим кучу разнообразных тел, которые взаимодействуют друг с другом некоторым образом. И чтобы разобраться в этих взаимодействиях, мы начинаем выделять силы - отдельные взаимодействия. Сила тяжести действует на брусок, он, в свою очередь, давит на стол, а стол в ответ сопротивляется силой реакции опоры. Есть сила трения между кирпичом и бруском, есть сила сопротивления воздуха, действующая на падающий шарик. Смотрите, в условиях (т.е. наблюдаемом мире) нет никаких сил, есть лишь взаимодействующие тела. Физика дает нам знание, что взаимодействия - это результат действия сил, рассказывает, какие силы бывают, от чего они зависят, как проявляются и т.п. Глядя на реальный мир, мы (в уме!!) раскладываем взаимодействие тел на силы, чтобы, используя физические законы из соответствующих теорий, спрогнозировать результаты этого взаимодействия.

Упражнение с выделением поведенческих ролей очень похоже на то, как выявляются силы при решении физической задачи. Чтобы начертить нужные силы на чертеже нужны теоретические знания: какие силы вообще бывают, чтобы их учесть. С ролями такая же история, но вот беда - нет на свете учебника, в котором бы все возможные роли были бы перечислены. И это еще один момент, который затрудняет понимание этого концепта. Т.е., чтобы получать от этого мыслительного инструмента заметную пользу, мало осознать, что можно и нужно декомпозировать взаимодействие и поведение людей на отдельные части, надо еще откуда-то знать, какие части выявлять, какие они вообще бывают.

Мне показалось, что аналогия с силами может помочь облегчить освоение ролей, как мыслительного инструмента, так как иллюстрирует сам принцип декомпозиции поведения на отдельные части. Но, конечно же, это не отменяет необходимости наличия насмотренности и кругозора, без которых не удастся понять, какие же роли выявлять и высматривать в людях вокруг.

Отличный чеклист о чем нужно не забыть спросить/подумать при проксировании интеграции

Я привез на Flow обновленную карту интеграций.

Обновлений много:

* Изменена структура: добавлены колонки "Семантика взаимодействия", "Стандарты", "Гарантии доставки"
* Добавлена семантика для REST: ресурсный стиль (REST уровня 2) и гипермедиа стиль (HATEOAS, REST уровня 3)
* Добавлены JSON:API, HAL, JSON-LD
* SOAP включен в асинхронные методы
* Добавлен WS-RM для SOAP — протокол гарантированной доставки
* Добавлены подходы к целостности транзакций: ACID и BASE
* Добавлено описание паттернов API Gateway и ESB
* Добавлено описание ETL-процесса
* Добавлена CAP-теорема
* Добавлено описание семантик гарантированной доставки
* Раздел "Особенности" объединен с разделом "Когда использовать"
* Исправлены опечатки

А самое главное — я, кажется, придумал шаблон для описания любой технологии интеграции!

Какие вопросы мы должны задать, когда смотрим на технологию?
1. Что это? Протокол, язык, набор принципов, конкретный продукт?
2. Какой верхнеуровневый паттерн? (по Грегору Хопу: файловый обмен, общая БД, удаленный вызов, сообщения)
3. Режим взаимодействия — синхронный или асинхронный? (скорость против пропускной способности)
4. Семантика запроса / интеграционный стиль: RPC, Query, ресурсный (REST 2 lvl — ресурсы и методы HTTP), гипермедиа (REST 3 lvl, HATEOAS), стриминг, публикация/подписка — в общем, как мы смотрим на интеграцию?
5. Протокол: опираемся на HTTP или используем что-то низкоуровневое? Если HTTP — то используем ли строку запроса и хедеры? То есть, получится ли подключить кэширование, маршрутизацию и все эти готовые штуки?
6. Формат сериализации: текстовый или бинарный? Есть ли схема? Обязательна ли она? Насколько строгая типизация? Есть ли сложные структуры: вложенные объекты, массивы, maps, множества?
7. Есть ли возможность определять и передавать кастомные ошибки?
8. Есть ли встроенные средства гарантированной доставки, и какие семантики поддерживаются?
9. Что с безопасностью? Шифрование, аутентификация, контроль прав.
10. Скорость сериализации / десериализации, размер сообщений
11. Есть ли инструменты преобразования данных?
12. Есть ли язык определения интерфейсов / спецификаций?
13. Статус стандартизации / распространенность / надежность / поддержка в разных языках и фреймворках
14. Какие особенные фишки есть у технологии?
15. С какими проблемами мы столкнемся?

Вот такие 15 вопросов, возможно ещё что-то появится. Но уже с этим можно оценивать и сравнивать разные технологии — насколько они близки, что будет стоить переход и имеет ли он смысл, как вообще об этом думать.

Ссылка на актуальную версию карты: https://disk.yandex.ru/i/k69r0Qr39_1P-w

Что archimate грядущий нам готовит... #archi #archimate

https://habr.com/ru/posts/932602/

Про модель Кано

В бытность свою продуктологом я узнал, что есть такая прикольная штука - модель Кано. Японский профессор Нориаки Кано придумал её в 80-х годах для анализа лояльности и удовлетворенности клиентов продуктом. Он обнаружил, что не все фичи/характеристики одинаково полезны, и что с точки зрения влияния на лояльность клиентов их можно разложить на пять кучек.

Сейчас меня интересуют три из них:
- 🎉 Привлекательные (Attractive) — неожиданные или дополнительные функции, которые вызывают восторг при наличии, но отсутствие их не вызывает неудовольствия.
- 📈 Одномерные (One-Dimensional) — характеристики, которые прямо влияют на степень удовлетворённости: чем лучше, тем выше удовлетворение.
- 🧐 Обязательные (Must-be) — базовые характеристики, без которых продукт не приемлем, но их наличие воспринимается как должное и не повышает удовлетворённость.

Замечено, что есть тенденция постепенного переползания функций из привлекательной кучки в обязательные. Так, когда-то давным-давно наличие камеры в телефоне было дополнительной привлекательной фишкой, а сейчас телефон без камеры не воспринимается в принципе. Другой пример - группировка писем в цепочки, впервые сделанная в GMail, теперь является базовой функцией любого email-клиента. Эффект чисто психологический, что бы удивительное ни было предложено, клиенты к этому привыкают и постепенно начинают воспринимать как само собой разумеющееся.

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

Например, когда идет речь о разработке простенького микросервиса в составе большого решения, который принимает команды, скажем, по REST, сохраняет состояние в своей базенке и отправляет события в кафку, я почему-то ожидаю, что без дополнительных слов и указаний этот сервис будет:
- Реализован в концепции stateless, т.е. у него не будет своего состояния и его можно масштабировать без дополнительных приседаний
- Иметь базовый набор метрик (счетчики количества и длительности обработки запросов, обращений к БД, потребления CPU и памяти)
- Сохранять структурированные логи с атрибутом трассировки, позволяющим связать записи, относящиеся к одному запросу
- Реализовывать какие-то базовые механики устойчивости к сетевым сбоям, например Retry с переменным временем ожидания при обращениях по сети к кафке или СУБД.

Т.е. этот набор характеристик в моём восприятии уже относится к обязательным. А вот реализованный Circuit Breaker в этот набор не входит, я его воспринимаю как что-то среднее между привлекательными и одномерными характеристиками - хорошо (но не удивительно) если оно есть, но не так страшно, если его нет.

А у вас какие ожидания перешли из области удивительного в пространство обязательного?

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

http://agilemindset.ru/item-estimation/

А Саше спасибо за ревью статьи 🙂

Скажу честно, читать и изучать некогда. Но размах, масштаб и намерения Дениса вызывают восхищение и уважение.

Собрали с новейшей 5.1 Про
свежую нейрокнигу:

Проектирование баз данных для бизнес-аналитиков

Кому
- Бизнес-аналитикам, которые:
- уже пишут требования к данным, отчётам, интеграциям;
- регулярно страдают от «не так поняли», «не то посчиталось», «надо было ещё один разрез».
- Руководителям отделов бизнес-анализа, которым нужно «подтянуть» команду в понимании данных, но не делать из них админов/архитекторов.

После прочтения аналитик перестаёт говорить «ну вы там как-нибудь в базе сделайте», и начинает:
- формулировать требования в терминах сущностей, связей, событий и состояний;
- понимать, *почему* разработчики предлагают такую структуру данных;
- предвидеть типовые грабли в отчётности и интеграциях.

Книга не про то, «как писать SQL», а *«как думать о данных так, чтобы базы данных и отчёты потом получались адекватные»*.

---

Часть I. Как бизнес превращается в данные

1. Зачем бизнес-аналитику понимать базы данных
2. От бизнес-языка к сущностям и событиям
3. Концептуальная модель для бизнес-аналитика

Часть II. Логическая модель и основы реляционного мира

4. Реляционная модель простыми словами
5. Нормализация для тех, кто не хочет знать слово «нормализация»
6. Справочники, классификаторы, иерархии

Часть III. Типовые паттерны данных бизнес-систем

7. Транзакции, документы, движения
8. Состояния и жизненные циклы
9. Баланс, срезы, накопительные показатели

Часть IV. Проектирование для аналитики и отчётности

10. От требований к отчёту к структуре данных
11. Звёздочки, снежинки и хранилища
12. Качество данных: как аналитик может его не убить

Часть V. Как писать требования, которые не стыдно дать архитектору

13. Документы, которые помогают проектировать базы данных
14. Шаблоны описания данных для требований
15. Антипаттерны в требованиях к данным

Часть VI. Кейсы: от описания бизнеса до схемы БД

16. Кейс 1: Интернет-магазин
17. Кейс 2: Подписочный сервис (SaaS)
18. Кейс 3: Операционный учёт + управленческая отчётность
19. Типовые грабли и как их обходить

Приложения

А. Чек-листы для BA
Б. Мини-справочник терминов для BA
В. Рекомендуемая литература

Самому писать нет ни времени, ни сил. Буду пользоваться чужими трудами. Сергей прекрасно изложил суть ограниченных контекстов в ddd.

О декомпозиции через Ограниченные Контексты

Декомпозиция - абсолютно некорректный термин, который тем не менее встречается повсеместно и потому сбивает с толку. И потом очень сложно донести то, что действительно подразумевается под связью между доменом и ограниченным контекстом в DDD.

Туда же и декомпозицию монолита на микросервисы (что тоже некорректная формулировка и подход).

Давайте разбираться.

Традиционная «декомпозиция системы» в инженерном понимании почти всегда подразумевает:
1. есть единая целостная модель системы
2. мы делим ее на части
3. части в совокупности «покрывают» целое (часто еще и без пересечений или с минимальными пересечениями)

В таком понимании:
- есть единое целое,
- есть разбиение этого целого

Внезапно, Bounded Context так не работает. И переход от монолита к микросервисам так не работает :)

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

То есть мы не делим модель на куски, мы конструируем несколько моделей, которые опираются на:
- свой лексикон (Ubiq. Language)
- свои инварианты
- свой контекст применения

То есть Ограниченные Контексты выделяются из предметной области.

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

Ровно поэтому для получения независимых сервисов сначала воссоздается предметная область, затем из нее выделяются модели, ограниченные определенным контекстом, и уже они наполняются данными и бизнес-логикой из монолита и, внезапно, какие данные и логика вполне могут начать «дублироваться», какие-то разделяться, какие-то группироваться, потому что наполняют собой разные модели в разных контекстах.