Прочел статью Документирование архитектуры: введение и решил описать изложенное с другим подходом.
Диаграммы не буду расписывать в текст, попробуйте прочесть их на языке Archimate. Представьте, что вы расшифровываете египетское иероглифическое письмо. Вот подсказка — набор символов для расшифровки Summary of Language Notation
Описание мотивации и стратегии
Напомню введенное ранее мной определение:
Архитектура – это проектное решение, которое набор проектных решений организует в Систему, соответствующую целевому назначению.
Значит нужно определится с целевым назначением системы. Напрямую цели и требования нам не заданы, но можно рассмотреть всё более масштабно используя подход JTBD.
Слой бизнеса и слой приложений
Допустим, что «Человек» из имеющихся альтернатив выбрал информационный продукт «Блог».
Продукт цифровой, поэтому слой бизнеса (функциональная архитектура) и слой приложений (прикладная архитектура) можно стыковать сразу.
При этом сервисы «Комментирование» и «Управление комментариями» пока не будут использоваться, так как модерация требует ресурсов времени.
Технологический слой (технологическая архитектура)
Для ведения блогов есть много платформ, «с нуля» ничего реализовывать не нужно. Для выбора конкретной платформы нужно на основании требований (которые, увы, не заданы) составить сравнительную таблицу. Можно дополнить ее другими критериями. Тут я думаю всё понятно. Допустим выбрали Ghost CMS, Apache HTTP Server и MySQL.
Теперь нужно разместить это всё в какой-нибудь инфраструктуре, которую тоже выберем по соответствующим критериям. Пусть будет GCP.
Резюме
Ну вот как бы и всё. Да, я понимаю, что мало объяснений.
Какие могут возникнуть вопросы:
1) Можно ли разместить всю информацию на одном изображении?
Ответ: Да, если требуется проконтролировать связанность. Но нужно соблюдать баланс и аккуратно стыковать слои (бизнес, прикладной и технологический и др.). Чем меньше различных диаграмм вы создадите, тем меньше вероятность получить рассогласование. Чем больше элементов на диаграмме, тем сложнее понять смысл. Поэтому нужен баланс.
2) Можно ли использовать концепцию Viewpoint?
Ответ: Да, но следите чтобы диаграммы (Views) непротиворечиво стыковались друг с другом, иначе потом придется согласовывать людей, которые прочли ваши диаграммы. см. п. 1)
AlexBrown
Хабр велик!
Ноль комментариев. Шесть добавлений в «интересно» (закладки). Рейтинг аккуратно ползёт в минус.
Хабр такой хабр…
Undiabler
Достаточно расплывчатая статья, без объяснений, базирующаяся на такой же расплывчатой статье. Блок схемы всегда привлекают внимание, ожидаешь разложенную схематическую мысль. А по факту начинаешь всматриваться — намешано лишних сущностей, все сумбурное, детали неуместные (Блогер управляет контентом через API?!). Технически эта статья еще слабее той на которую опирается.
gimatdinov Автор
Вы видите где-нибудь стрелку от блоггера к API напрямую?
Блоггер работает через сервисы «Подготовка статей» и «Управление статьями», которые используют API. На чём конкретно сделан front я не указал.
FYI ghost.org/docs/api/v3
Undiabler
Так об этом речь и идет. На чем конкретно сделан front вы проигнорировали, зато уточнили что HTTP Server именно Apache, а база именно MySQL. Это называется отсуствие консистентности.
Представьте вы читаете инструкцию к телевизору, вы ожидаете получить общую информацию с определенном уровнем погружения в детали. А не две странички: вот телевизор, вот кнопка вкл, а потом двести страниц документации и чертежей от пульта телевизора.
gimatdinov Автор
Я думаю, вы критикуете не смысл статьи. В данном случае, как реализован фронт не так важно, по большей части, это статические страницы и посты, это блог, а не интернет магазин.
Я также считаю, что вы не разобрались в исходной статье и почему эта статья указана как (remastered).
gimatdinov Автор
Можно использовать Ghost Admin ghost.org/docs/concepts/admin
А можно:
But, our default client app isn't the only way to interact with content on the Ghost Admin API. You can send data into Ghost from pretty much anywhere, or even write your own custom admin client if you have a particular usecase which requires it.
gimatdinov Автор