Диаграмма контейнеров позволяет...показать состав вашей системы на уровне контейнеров! :Dпоказать, из каких приложений и хранилищ данных состоит ваша система, а также какие технологические решения приняты.
Создается, как бы, кхм, тоже не сложно - берешь центральный элемент с программной системой и заменяешь его на набор контейнеров. Взаимодействия перепривязываешь к ним.
Переведу все же часть списка с сайта модели, что может быть контейнером (из полезного для аналитиков):
〰️ веб-приложение на стороне сервера (читай, все наши любимые (микро)сервисы)
〰️ веб-приложение на стороне клиента (упростим до frontend'а)
〰️ мобильное приложение
〰️ десктопное приложение
〰️ база данных (но в ней есть свои нюансы, рекомендуемые Саймоном, рассмотрим позднее, не переключайтесь ❤️)
Но! Все же полезно помнить про "единицы развертывания". У Саймона в книгах и на сайте есть примеры, когда frontend технически развертывается несколькими отдельными контейнерами... Я, к стыду своему, ничего в техническом плане во frontend'е не понимаю (пока). Рассказываю, т.к. один квадратик "Frontend App" может быть не правдив. А может и наоборот. Есть у меня пунктик это понять...
Нужна для: понимания структуры ПО и обязанностей его составляющих, принятых технологических решений и взаимодействия контейнеров.
Элементы, присутствующие на диаграмме: программные системы, действующие лица, контейнеры.
Наличие технических деталей: Да. Указываем технологии для контейнеров и взаимодействий с ними (например, языки программирования, протоколы, по которым идет взаимодействие, технологии, выбранные для интеграций, etc)
А что, если я еще не знаю технических деталей?
Не страшно. Если вы знаете хоть что-то, даже не все - укажите. Если команда выбирает между несколькими технологиями - укажите, что "идет выбор из".
Аудитория: Технические специалисты внутри и вне вашей команды.
Рекомендуется ли к созданию автором модели: Да.
Потом посмотрим, как Саймон рекомендует отображать микросервисы, базы данных и брокеры сообщений на этом уровне. Так что правда, не переключайтесь 🥰