Продолжение вчерашнего поста про новую книгу о C4.
—————————————
Глава 10. Нотация. Курсивом выделено в нескольких местах, что C4 notation independent (теперь у меня будет еще сильнее дергаться глаз, когда C4 называют нотацией 😅).
Самое для меня революционное:
What about using UML or ArchiMate as the notation for C4 model diagrams? Yes, you can absolutely do this, because...
После because поясняется, что модель C4, это же, по сути, идея абстракций и диаграмм. Вы можете взять эту идею, наложить сверху UML как нотацию (по типу стрелок и т.п.), и будет вам счастье. Не припомню, чтобы ранее я где-то встречала именно такое описание.
Интересно почитать раздел про аббревиатуры и нейминги:
I’ve met many organizations that have named their software systems more esoterically. Names from Greek mythology are more common than you would think! Although existing team members might understand what “Plutus” is (the payment service), imagine the confusion of new hires who see your architecture diagram full of Greek names for the first time.
Хех. Помню, на одном проекте у нас почтовый сервис "Печкин" назывался.
В части способа отображения элементов интересное замечание, что культурные и региональные нормы могут влиять но это отображение. Дескать, на английском мы читаем слева-направо, поэтому и элементы располагаем также, слева - сервисы, справа - БД.
И интересно посмотреть на примеры отображения стрелок между элементами. Самое подробное описание взаимодействий, что я пока встречала.
—————————————
Глава 11. За пределами основ.
Интересно посмотреть на:
1. Раздел о Hardware Systems - есть мини-пример диаграммы системного контекста, где добавлена абстракция hardware system. При этом в разделе и далее в книге есть примечание, что C4 не разрабатывалась под hardware'рные системы.
2. Раздел Abstraction Versus Organization - хороший пример, чем отличается идея абстракций от идеи организации кода. Ну и в целом, кто придерживается мнения, что 4-х модели уровней не достаточно - тут есть самое большое пояснение на тему, что я помню.
3. Раздел Software Systems Versus Feature-Based Teams - а что если вы, как команда, можете менять нужные сервисы в зависимости от разрабатываемой фичи? Т.е. у вас нет той единой "зоны ответственности", которая нужна для определения вашей программной системы как абстракции? В этом разделе есть предложение, как с этим жить.
Глава 12. Модель C4 на практике. Раздел A Silver Bullet? честно рассказывает, когда модель подходит больше, а когда меньше. Мне отдельно понравилось вот это:
This next point may seem obvious to you, but it doesn’t seem to be obvious to everybody. The C4 model diagrams need to be accompanied by supplementary documentation. The C4 model diagrams provide a way to understand how the software has been decomposed into smaller building blocks (the four static structure diagrams), how individual features work at runtime (dynamic diagrams), and how the software is deployed into various deployment environments (deployment diagrams). In short, the diagrams show the outcome of the decision-making process. The diagrams don’t tell you why those decisions were made.
Не помню, чтобы ранее где-то подчеркивалось то, что документация все равно нужна.
В разделе Tooling можно почитать о разнице понятий diagramming и modeling. Не уверена, что они какие-то общепринятые, но можно посмотреть на это глазами Саймона. Сам он за modeling, к слову.
Раздел Scaling the C4 Model как будто бы особо нового не принес - если у вас большие диаграммы, то делите их на кусочки, делайте perspectives (мне ближе слово view), объединенные какой-то идеей, не рисуйте общие элементы типа компонентов логгирования. Часть про альтернативные визуализации тоже не сильно обновлена.
Раздел Artificial Intelligence - крайне небольшой, есть замечание, что AI лучше воспринимает текстовый структурированный формат описания вашей архитектуры. И дальше скрин, где Саймон, кажется, скормил модели описание из своего Structurizr. Три идеи взаимодействия с ИИ - дать агенту сравнивать текущую и ожидаемую архитектуру на предмет расхождений, генерировать модель архитектуры ИИшкой из кода, просить ИИ что-то доработать, задавая границы контейнером или компонентом.
Раздел Diagramming Capability Maturity интересен, если нравятся некие общие концепции. Там представлена модель зрелости организации относительно диаграмм: на уровне 1 архитектурных диаграмм вообще нет, на уровне 5 - есть единый инструмент моделинга, архитектурные элементы реверс-инжинирятся из кода и т.д. Указано, какие уровни охватывает C4.
—————————————
Вот, в целом, и всё.
Надо теперь подумать, как красиво обновить свои материалы по C4. И закончить посты на тему модели 😅