Вот эту схему вам ещё, кажется, не показывал. Все области знаний по архитектуре! От сообщества DNA, это какие-то польские ребята, случайно наткнулся.
Люблю обобщающие схемы! Вы уже, наверное, поняли.
Про разбивку, конечно, можно спорить, но давайте посмотрим, что мы тут видим.
Во-первых, 4 области: * Системы * Решение * Инфраструктура * Приложение
Давайте начнем с решения. Тут у нас 4 раздела: * Область проблемы * Визуализация * Принятие решений * Область решения
(Опять проблемы с русским языком — не отличаем solution от decision)
Что тут интересно: область проблемы — это сразу DDD, выделение доменов и поддоменов (ядро бизнеса, поддерживающие, общие), и Event Storming. Всё, нету никаких требований и функций, есть только домены. В принципе, для архитектора этого может быть и достаточно — ему же нужно разбить систему на части, так чтобы они не были сцеплены и изменения были изолированы, и на этом всё.
Хороший блок про принятие решений. OODA, надо же. Это нужно подробнее разобрать, надо бы пост отдельный сделать.
В области решений есть про Закон Конвея — это важно для архитектора, они правда этим довольно часто занимаются — распределяют команды по сервисам и системам.
В инфраструктуре — сплошные облака и контейнеры, но это наверное и правильно. И это то, что обычно наиболее далеко от аналитика. Так что если думаете про карьеру архитектора — нужно с этим разбираться. Там много всего интересного. Ну и инфраструктура как код.
Область приложений — это про то, о чем обычно все книги, статьи и курсы по архитектуре. Архитектура отдельного приложения: гексагональная, микроядерная, трёхзвенная, модульная, каналы-и-фильтры. Как можно извратиться, пока всё это ещё считаетс одним приложением. Проверьте себя, знаете ли вы все эти баззворды :)
Область систем — это в основном про распределенные системы. Тут мне особенно нравится раздел 'Invalid assumptions during system distribution' — ложные представления при проектировании распределенных систем (нулевая задержка передачи, надежные сети, бесконечная пропускная способность, защищенные сети, топология не меняется, есть только один администратор, стоимость передачи данных равна нулю, сеть гомогенна — тут всё прекрасно!)
И 'Reasons for system distribution' — основания для распределения. Почему вы хотите распределенную систему, а не монолит? Это всё совсем не бесплатно. Вы решаете организационную проблему или техническую?
Большой кусок про микросервисы, с перечислением "за" и "против", и раздел про коммуникации, где живут наши интеграции (ну ещё захватывая раздел "шины").
В общем, козырная схема. Даже не знаю, что добавить. Сначала хотел придраться к структуре команд и обратному закону Конвея — но он упомянут в области решений и в микросервисах. Потом — к схемам и контрактам, но про них есть в коммуникациях. Про брокеры сообщений есть в разделе Fire-and-Forget. Вот фитнесс-функции куда-то потерялись, в явном виде не упомянуты.
Разбор всей схемы тянет на хорошую такую учебную программу месяцев на 8. Или на 6 отдельных курсов 😉
Как минимум, можно проверить себя: что из этого я знаю и использовал, о чем знаю только теоретически, и про что не знаю ничего. и составить план по изучению в режиме self paced learning.
Вот эту схему вам ещё, кажется, не показывал. Все области знаний по архитектуре! От сообщества DNA, это какие-то польские ребята, случайно наткнулся.
Люблю обобщающие схемы! Вы уже, наверное, поняли.
Про разбивку, конечно, можно спорить, но давайте посмотрим, что мы тут видим.
Во-первых, 4 области: * Системы * Решение * Инфраструктура * Приложение
Давайте начнем с решения. Тут у нас 4 раздела: * Область проблемы * Визуализация * Принятие решений * Область решения
(Опять проблемы с русским языком — не отличаем solution от decision)
Что тут интересно: область проблемы — это сразу DDD, выделение доменов и поддоменов (ядро бизнеса, поддерживающие, общие), и Event Storming. Всё, нету никаких требований и функций, есть только домены. В принципе, для архитектора этого может быть и достаточно — ему же нужно разбить систему на части, так чтобы они не были сцеплены и изменения были изолированы, и на этом всё.
Хороший блок про принятие решений. OODA, надо же. Это нужно подробнее разобрать, надо бы пост отдельный сделать.
В области решений есть про Закон Конвея — это важно для архитектора, они правда этим довольно часто занимаются — распределяют команды по сервисам и системам.
В инфраструктуре — сплошные облака и контейнеры, но это наверное и правильно. И это то, что обычно наиболее далеко от аналитика. Так что если думаете про карьеру архитектора — нужно с этим разбираться. Там много всего интересного. Ну и инфраструктура как код.
Область приложений — это про то, о чем обычно все книги, статьи и курсы по архитектуре. Архитектура отдельного приложения: гексагональная, микроядерная, трёхзвенная, модульная, каналы-и-фильтры. Как можно извратиться, пока всё это ещё считаетс одним приложением. Проверьте себя, знаете ли вы все эти баззворды :)
Область систем — это в основном про распределенные системы. Тут мне особенно нравится раздел 'Invalid assumptions during system distribution' — ложные представления при проектировании распределенных систем (нулевая задержка передачи, надежные сети, бесконечная пропускная способность, защищенные сети, топология не меняется, есть только один администратор, стоимость передачи данных равна нулю, сеть гомогенна — тут всё прекрасно!)
И 'Reasons for system distribution' — основания для распределения. Почему вы хотите распределенную систему, а не монолит? Это всё совсем не бесплатно. Вы решаете организационную проблему или техническую?
Большой кусок про микросервисы, с перечислением "за" и "против", и раздел про коммуникации, где живут наши интеграции (ну ещё захватывая раздел "шины").
В общем, козырная схема. Даже не знаю, что добавить. Сначала хотел придраться к структуре команд и обратному закону Конвея — но он упомянут в области решений и в микросервисах. Потом — к схемам и контрактам, но про них есть в коммуникациях. Про брокеры сообщений есть в разделе Fire-and-Forget. Вот фитнесс-функции куда-то потерялись, в явном виде не упомянуты.
Разбор всей схемы тянет на хорошую такую учебную программу месяцев на 8. Или на 6 отдельных курсов 😉
Как минимум, можно проверить себя: что из этого я знаю и использовал, о чем знаю только теоретически, и про что не знаю ничего. и составить план по изучению в режиме self paced learning.
