Дочитала новую книгу Брауна. Что могу сказать - он, как всегда, на редкость последователен в своих суждениях, за уже год сбора информации по C4 у меня не вышло найти противоречий :)
Общее впечатление: есть, что посмотреть, относительно прошлых книг, выступлений и сайта о модели. Ниже первая часть краткого summary, на что я обратила внимание в каждой главе.
Важно: я провожу сравнение относительно своих знаний о модели (они аккумулированы тут, если что, а еще есть незаконченная серия постов). Ваши инсайты после прочтения книги, конечно, могут отличаться 🙂 Если ниже в списке глава пропущена - значит, я там не нашла для себя сюрпризов.
—————————————
На что обратить внимание в целом: в каждой главе про ту или иную диаграмму добавился пошаговый пример ее создания. Иногда даже не один. Если вам не хватало подобных примеров - теперь можно взять напрямую из книги. Общий пример при этом - сквозной, т.е. диаграммы создаются для одной системы, любимой Брауном Financial Risk System.
—————————————
Глава 2. Про абстракции. Искренне надеялась, что вот эта фраза про контейнеры:
The key thing about understanding a software system from a containers perspective is that any inter-container communication is likely to require a remote interface such as a SOAP web service, RESTful interface, Java RMI, Microsoft WCF, messaging, etc.
из его старой книги Software Architecture for Developers будет включена в описании абстракции контейнера. Наверное, во многом потому, что она удобна аналитику, нам так понятнее, чем "единица развертывания". Но нет, он не написал про это. Что же, продолжу ссылаться на другую книгу.
—————————————
Глава 3. Диаграмма системного контекста. Можно обратить внимание на уточнение об акторах, которых Саймон включает на диаграмму. Он там рассуждает, когда стоит включать на диаграмму тех, кто пользуется системой ради какой-то бизнес цели, а когда - системных администраторов, operational staff и пр.
Также впервые на его примере диаграммы увидела отображенное взаимодействие между внешней программной системой и актором. Ведь обычно это были только взаимодействия с центральным элементом - "нашей" программной системой. К слову, на сайте пример уже тоже новый.
—————————————
Глава 4. Диаграмма контейнеров. Увидела достаточно жесткое отделение диаграммы контейнеров от диаграммы развертывания:
An important point to note here is that container diagrams should say very little (ideally nothing) about deployment aspects such as cloud environments, servers, Kubernetes clusters, Docker containers, load balancers, firewalls, API gateways, failover, and so forth.
Он это и раньше говорил, просто теперь максимально категорично :)
Но теперь этому есть и объяснение, идущее сразу следом - развертывание может сильно отличаться от окружения к окружению (тест, прод и вот это вот все). Поэтому контейнерная диаграмма, которая про архитектуру, и должна быть свободна от этих деталей. А вот диаграммы развертывания рисуются отдельно под каждое окружение.
Добавлено расширенное пояснение по потенциальной аудитории диаграммы.
—————————————
Глава 5. Диаграмма компонентов. Обратила внимание на эту цитату:
Similarly, if your container makes use of components organized in a “ports and adapters” or “hexagonal” style, the diagram should reflect this.
Подобное было и в прошлой книге, но как будто мягче. Если я правильно помню, там было что-то в стиле "в идеале, диаграмма компонентов должна отображать, в каком стиле организован код". А здесь прямо-таки должна отображать (да, не must, а should, но все же).
Новое большое пояснение, когда рекомендована диаграмма, а когда - нет.
—————————————
Глава 7. Динамическая диаграмма. Теперь у нее есть, ахах, две предлагаемых формы - в стиле диаграммы коммуникации UML и в стиле диаграммы последовательности. Обновленные примеры также есть на сайте. Иронично - Саймон всегда говорит о сложности UML и о том, что мало кто им пользуется на его опыте... Почему-то на этом фоне такое усиление связи с UML меня забавляет :D
Также расширено пояснение по потенциальной аудитории диаграммы.
—————————————
Глава 8. Диаграмма развертывания. В scope диаграммы отмечено, что можно отобразить не одну, а несколько программных систем, если они развернуты на одной инфраструктуре. Если вам это зачем-то нужно и/или по каким-то причинам так удобнее. Раньше, мне казалось, была речь про одну, но мб я ошибаюсь.
Самым ценным же тут выглядит пример. Их на самом деле два - для разных окружений. Посмотришь такое, и сразу очень хорошо видно, почему не надо мешать диаграмму контейнеров с диаграммой развертывания.
—————————————
Всё в один пост у меня не влезло, продолжение будет завтра 👍