Записки системного архитектора

В официальном твиттер-аккаунте The Open Group, посвященном ArchiMate, позавчера снова появилась ссылка на кликабельный Language Notation Guide

Спасибо прекрасному каналу "Архитектура ИТ Решений" за ссылку на пост https://www.jamesmichaelhickey.com/consistency-boundary/
С одной стороны, никаких особенных открытий там не прозвучало, а с другой стороны, как-то по новому для меня зазвучала фраза, что границы агрегата определяются не столько границами сущностей и их свойств, сколько инвариантами/бизнес-правилами.
Агрегат должен быть как можно меньшего размера, чтобы снизить возможную конкуренцию, но при этом включать все данные, необходимые для контроля и соблюдения инварианта.

🚀Ну вот и первое внешнее мероприятие нашего сообщества!

Мы приглашаем всех неМТСовцев на первую встречу True Tech Arch, регулярную внешнюю конференцию МТС в профессиональном сообществе Архитекторов!
Детали и регистрация по ссылке.
🔜Скорее расскажите всем неравнодушным к IT архитектуре друзьям.

Участие бесплатное, но важно заранее зарегистрироваться, чтобы получить приглашение, так как количество мест ограничено.

МТС делится информацией о внутренней кухне корпоративной архитектуры

3. Кроме собственно потоков и их направления важно отразить на схеме сетевые зоны, в которых располагаются участники информационного обмена. Если обмен информацией происходит внутри защищенного периметра, то требования к способам аутентификации и защите каналов, по которым происходит передача информации, существенно ниже, чем в случае, когда информационный обмен происходит по внешним, неподконтрольным каналам связи.

2. В описании информационных потоков обращаем внимание на направление информационного обмена, и помним, что направление обмена не обязательно совпадает с направлением сетевого подключения. Например, клиент подключается к серверу, т.е. стрелочка на HLD-диаграмме будет от клиента к серверу. Да, клиент запрашивает информацию у сервера, и потом информация движется обратно, от сервера к клиенту. Большинство информационных потоков - двусторонние, построены по модели запрос-ответ. Нужно не лениться и отдельно описывать содержание потока каждого направления.

1. Говоря об информационных потоках между системами и/или пользователями, безопасников интересует в первую очередь адекватность мер защиты при передаче информации и содержания передаваемой информации. Поскольку они редко могут себе позволить глубоко погружаться в контекст каждой информационной системы, которую они анализируют, то для простоты оценки адекватности мер защиты информацию принято разделять по категориями - общедоступная, служебная, персональные данные, коммерческая тайна, гостайна и т.п. Для каждой категории - свои правила и требования по защищенности. Поэтому описывая содержание информационных потоков концентрируемся на указании ключевых сущностей, которые попадают под знаковые категории. Перед описанием содержания потоков полезно ознакомиться со списком значимых категорий и описание данных, которые под эти категории попадают. Обычно этот перечень содержится в политике информационной безопасности организации, в положении о коммерческой тайне и других подобных документах, которые подписывают все (или почти все сотрудники), но мало кто их читает :) , В дополнение к бизнес-данным не забывайте указывать в том числе и способ передачи аутентификационной информации - где-то это логин пароль, а где-то JWT-токен.
Например:
Клиент -> Сервер: Аутентификация: токен аутентификации (JWT), Запросы на получение данных о заказах клиента, включает идентификатор заказа.
Сервер <- Клиент: Данные о запрошенном заказе клиента, включая персональные данные клиента (номер телефона, адрес, паспортные данные), перечень товаров и общая стоимость заказа.

Для вывода важной информационной системы в промышленную эксплуатацию обычно нужно получить одобрение со стороны специалистов по информационной безопасности. Среди документации, которую они требуют, присутствуют схема, перечень и описание информационных потоков. По опыту, составление этих схем и описаний представляет определенную сложность и для разработчиков, и для архитекторов, и для аналитиков, так как это представление немного с другой точки зрения, чем они привыкли.
Это описание будет легче составить, если понимать, на что именно смотрят ИБ-шники.

Event Sourcing — это паттерн проектирования в информационных системах, который заключается в сохранении состояния системы путем сохранения истории всех событий, происходящих в системе.

Вместо того, чтобы сохранять текущее состояние объекта, система сохраняет все события, произошедшие с объектом, и воссоздает текущее состояние, используя эти события.

Когда происходит изменение состояния объекта, система создает новое событие и сохраняет его в хранилище событий. Это событие содержит информацию о том, что произошло, а не о текущем состоянии объекта. При необходимости система может воссоздать текущее состояние объекта, применяя все события из хранилища событий.

➖Хотите узнать подробнее, что такое event sourcing и какие преимущества и недостатки он имеет?
➖Хотите понять, какие трудности могут возникнуть при использовании этой технологии?

Тогда присоединяйтесь к нашему вебинару «Плюсы, минусы и подводные камни Event Sourcing», который состоится 28 cентября в 19:00 МСК

На вебинаре Станислав Щетинников из Сбера подробно расскажет о том, как на самом деле работает event sourcing, какие задачи он решает и какие преимущества он имеет. Мы также рассмотрим недостатки этой технологии и поделимся опытом в использовании event sourcing в реальных проектах.

Вебинар будет полезен разработчикам, архитекторам, техническим руководителям, которые хотят узнать больше о новых технологиях и подходах в разработке программного обеспечения.

✔️Подробности и регистрация

Как раскладывать события сервиса по топикам в кафке?

Может быть лучше делать гранулярные топики, и публиковать каждый тип в одном топике? Тогда у подписчиков полная свобода, они смогут гранулярно выбирать, на какие события подписываться. Но, правда, если консьюмер обрабатывает несколько типов событий и читает их из разных топиков, то гарантия порядка обработки событий теряется. Можно, конечно, сначала подчитывать события из разных топиков, сортировать их по метке времени, а потом уже обрабатывать... но и тут неприятный побочный эффект: пока мы собираем и сортируем события - увеличивается задержка.

Тогда может быть лучше складывать события в один топик? Так мы сможем гарантировать порядок событий, но, с другой стороны, если консьюмеру нужен только один тип событий, то он все равно вынужден просматривать все и выбирать нужные (вспоминается анекдот про сортировщика апельсинов).

К чему я все это. Выглядит так, что невозможно рационально принять решение о том, как стоит раскладывать события по топикам, находясь мыслями внутри продукта/сервиса. "Правильная" раскладка зависит от того, какие есть требования к пропускной способности, производительности, требованиям к КТС и т.п. системы в целом, от того, как система разбита на сервисы, сколько потребителей/консьюмеров событий и какие именно события они потребляют.

Т.е. структура топиков в микросервисной системе - это вопрос архитектуры не отдельных микросервисов, а системы, как целого.

"Есть такое понятие - девопс, ну или архитектор, мы его сейчас активно ищем" #ПодслушаноЗаСоседнимСтоликом

"Мы сейчас тестовое облако развернем на наших серверах" #ПодслушаноЗаСоседнимСтоликом

Уже неоднократно сталкивался с тем, как тяжело дается управление процессом создания сложных систем, на которыми работает множество команд.

Сначала все вроде идет хорошо и разумно. На старте проекта умные люди разбивают систему на части, собирают команды для разработки отдельных частей, а потом все идёт не то, чтобы плохо... но вот как-то не так, как задумывалось.
Команды отдельных подсистем смотрят больше внутрь, чем наружу, концентрируются на своем кусочке и его взаимодействии с другими подсистемами. Внутри команд возникает вполне себе дружба, синергия, развитие и эволюционная архитектура. Но прочерченные между подсистемами границы оказываются неожиданно очень жёсткими. На уровне всей системы командная работа сама по себе не возникает. И неважно, в одной организации эти команды, или в разных.

Если просто сложить в тазик печень, сердце, лёгкие и т.п., то человечек не сложится. Система - это не только компоненты, из которых она состоит, а ещё и связи между ними. И связи эти порой оказываются сложнее, чем сами компоненты.

После разделения ответственностей получается, что каждая команда отвечает за свою подсистему, а связи между системами неожиданно оказываются без хозяина, что приводит к неприятным побочным эффектам. И тут, как всегда есть две крайности - либо системы достаточно автономны и изолированы, тогда эти связи изменяются редко, либо подсистемы связаны сильно, связи живые, динамичные, активно развивающиеся.

В первом случае в архитектуре отдельных подсистем, которые во власти своих команд, поначалу все хорошо. Но если связи меняются редко, то, как правило, нет простых и доступных организационных механизмов изменения отношений между подсистемами. Чтобы что-то добавить или изменить нужно пройти 7 кругов ада и 18 раундов согласований. Итог - изнутри (каждой!) команды остальное окружение воспринимается уже как что-то далекое, чужое и неподвластное. Как следствие, проблемы, которые можно было бы решить уточнением и точечными изменениями контрактов или ответственностей на границах подсистем, решаются сложными компенсациями внутри каждой подсистемы. Сложность растет на ровном месте.

Во втором случае - напротив, динамичность связей необходима для развития и функционирования системы, поэтому сразу закладываются механики и организационные механизмы для их создания и изменения. Связи создаются и модифицируются, но практически бесконтрольно, так как создать их легко, но ответственного нет, документации по уже имеющимся отношениям нет, критериев допустимости нет и т.п. Поэтому связи и отношения растут как саксаул или как одуванчики на некошеном газоне. И неожиданно строгая и аккуратная архитектура на старте постепенно и незаметно превращается в перепутанный комок взаимодействий, хотя каждая подсистема по отдельности вроде как и ничего.

Интересно, с чем связаны эти эффекты? Это чьи-то недоработки или закон природы? Есть ли рецепты борьбы с ними или нужно признать, что это следствие особенностей человеческой психологии и смириться?

#накипело #мысливслух

И правда работает! Это очень сильно упрощает жизнь.

Новая версия Archi заявляет новую фичу - возможность изменять типы элементов и отношений! Пошел ставить и проверять.

Вот все вокруг говорят - DDD, ограниченные контексты... распиливают монолиты на микросервисы, изолируют и разделяют код по микросервисам...
А я вот все думаю: а к чему, к какому контексту (= сервису) относятся контракты по взаимодействию между сервисами? Кто "владелец" API, модели событий или graphQL схемы при взаимодействии сервисов между собой?
Вот, к примеру, есть два сервиса, один вызывает другой по ресту. И вроде бы отсюда следует, что тот, кто предоставляет API, является владельцем, поставщиком контракта, а вызывающая сторона - это клиент, он подстраивается под API. Но вдруг оказывается, что клиент - это большая система, к которой можно подключать плагины/расширители поведения и для этого они должны реализовывать определенный интерфейс. И сразу оказывается, что владельцем контракта является вызывающая сторона, именно она определяет "правила игры", а на реализующий сервер накладываются обязательства следовать контракту...
Такая же история может возникать и с событиями. Кто, какой сервис владелец схемы события - отправитель или получатель? Неправильный вопрос. Владелец схемы - это тот сервис, который определяет логику, смысл, содержание события. Когда-то это может быть сервис-источник события, который генерирует события и ему все равно кто их обработает, потребители подстраиваются под контракт. А может быть наоборот, источник события заинтересован, чтобы его события были обработаны конкретным получателем, и он "подстраивается" под возможности/контракты получателя, посылает события в определенном получателем формате, т.е. владельцем контракта становится получатель, обработчик события.

Видится, что владельцем контракта должен быть тот сервис (и, как следствие - домен), который является источником его потенциальных изменений. Т.е. владельца контракта нельзя определить глядя на архитектуру системы и отношения между её компонентами в моменте, а только лишь изучая и моделируя динамику её развития.

Открыл для себя формат yaml как отличный способ моделирования сущностей в текстовом представлении.

Раньше, когда мне нужно было сделать набросок объектной модели, прикинуть, какие сущности возникают в системе, какие у них могут быть атрибуты и т.п., то я либо писал какой-то псевдокод на c#/java/kotlin или чертил UML подобные диаграммки в draw.io или plantuml, А тут попробовал делать наброски в yaml и мне неожиданно понравилось. Удобный редактор VSCode добавляет интерактивности - перестановка строк, автоформатирование, сворачивание/разворачивание по уровням, подсветка комментариев и т.п. делают работу с наброском/моделькой простой и приятной. Минимум служебной информации (читай - информационного шума), концентрация полезной информации на пиксел экрана прямо запредельная.

Короче, если не пробовали - рекомендую.
#yaml #vscode #моделирование

Код, написанный с душой без ChatGPT и ИИ, в будущем будет цениться дороже. Примерно как фермерские продукты и машины, собранные вручную.

Один из самых болезненных недостатков Archi - отсутствие возможности изменить тип существующего элемента или связи. Ну ошибся я, вставил component там, где уместнее было бы сервис. Почему нельзя сменить тип квадратика с одного на другой с сохранением всех связей? зачем заставлять меня заново переносить все связи и вводить свойства?
#archi #боль

Уже во вторник, 1 августа, стоимость участия в ARCHDAYS вырастет. Успейте приобрести билеты по сниженной цене ✅

Тематики конференции:
1. Процессы проектирования
2. Инструменты проектирования
3. Практики проектирования
4. Обучение архитектуре
5. Собственная разработка

Зарегистрироваться: https://archconf.ru/the-price-is-rising