Прежде чем мы начнем — этот пост в блоге написала я, искренне ваша Хила (Hila). Но доработка, конкретные формулировки и доступный контент по этой теме в Augury созданы группой замечательных людей, включая меня :), Одеда (Oded), Надава (Nadav), Эяля (Eyal) и Ассафа (Assaf).

Пролог

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

Рождение архитектурного форума

“Закон Конвея” утверждает, что для функционирования программного модуля несколько авторов должны часто общаться друг с другом. Поэтому структура программного интерфейса системы будет отражать социальные границы организации, которая ее создала. Для достижения быстроты, автономии и влияния на бизнес мы оптимизируем работу, обеспечивая возможность распределения командной ответственности за архитектурные компоненты.

Чтобы достичь всего этого, нам необходимо согласование между командами, флитами (группа R&D), а иногда и между R&D (англ. Research and development — исследования и разработки). Компания Augury решила создать новую персону в каждой R&D: архитектор. Основными обязанностями архитектора являются:

• Понимание и влияние на стратегию продукта путем создания архитектурного видения, рекомендаций и дорожной карты.

• Наставлять и направлять SW-инженеров, помогая им повышать мастерство.

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

• Постоянно совершенствовать наши процессы проектирования и доставки совместно с продакт-командами и R&D, чтобы решать текущие/будущие проблемы, связанные с масштабированием Augury.

Если бы мне нужно было дать определение одной фразой, я бы сказал: "Архитекторы - это проводники изменений, а не лица, принимающие решения". Если наши архитекторы являются проводниками "закона Конвея", им нужен специальный штаб. Так и родился архитектурный форум. Архитектурный форум — это место, где архитекторы собираются вместе и формализуют то, что мы видим происходящим во флитах. Мы проводим еженедельные встречи для обсуждения тем, создания контента и вынесения проблем для рассмотрения.

На этой фотографии вы можете видеть нас во время встреч google Meet, когда мы работаем в гибридной модели.

История о DDD в Augury

Давным-давно жил-был бэкенд-разработчик по имени Одед. Будучи ветераном Augury, Одед выполнял захватывающую миссию по структурированию наших архитектурных рекомендаций. “Давным-давно" — это год назад. Когда Augury начала расширяться как компания, стало ясно, что нам нужно действовать как можно быстрее, чтобы не достичь точки невозврата. Необходимо было действовать до того, как наша команда R&D станет слишком большой, и распространять новые идеи и соглашения будет слишком сложно.

Так был создан наш учебник "DDD в.1", получивший название "Учебник по архитектуре Augury". Одед общался со многими компаниями. Его целью было собрать информацию и взять на вооружение то, что подходит для нашего конкретного случая использования. Мы разработали определения для наших структурных элементов DDD и изложили различные правила и рекомендации.

Мы пользовались этим учебником почти год, но обнаружили, что в нем трудно ориентироваться, так как он перегружен контентом. Чтобы найти ответы на интересующие вопросы, требовалось определенное знакомство с ним. В результате только небольшая группа людей смогла полностью освоить руководство. Мы хотели разорвать "цепочку обязанностей" и найти лучший способ распространить эти знания среди различных R&D групп.

Практическое применение — все зависит от распространения информации

Будучи растущей компанией, мы не в первый раз внедряем изменение парадигмы распространения информации и знаний. Первый шаг действительно начался, когда Augury перешла на многопрофильные продакт-сквады (команды), которые реализовали концепцию под названием "разработчик в центре". Этот подход был направлен в основном на обеспечение автономии путем повышения вовлеченности продукта и сокращения количества операций по передаче данных в процессе доставки. Это долгая история, и я могу показать вам хорошую сессию Ассафа на эту тему (на иврите, извините).

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

Руководящие принципы должны быть следующими:

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

• Удобные для ссылок — к ним всегда можно обратиться внутри DR, что позволяет легко перейти к конкретной теме внутри проекта с помощью ссылок, устраняя необходимость неоднократно открывать дискуссии по одному и тому же вопросу.

• Живой документ — он должен легко комментироваться и обновляться, если руководство меняется по мере того, как мы улучшаем понимание наших юзкейсов и домена.

Поэтому мы решили отказаться от "книги" и вместо этого создать словарь определений, который будет дополнен "архитектурными темами". “Архитектурная тема" — это паттерн или вопрос, в который мы хотели бы глубоко погрузиться и получить конкретные рекомендации. Мы остановились на этом формате, потому что нам нужен простой способ поделиться конкретными рекомендациями по уникальным вопросам, которые мы постоянно видим в дизайн-ревью. Это должно быть так же просто, как добавить ссылку.

После того как были готовы наши основные темы, мы решили создать серию открытых сессий со всеми R&D — "Augurian Architecture". В каждой сессии мы фокусируемся на одной теме и проводим обсуждение вокруг выдающихся юзкейсов и значимых дилемм. Продолжительность сессий составляет один час, 20 минут отводится на определения. Оставшиеся 40 минут направлены на открытый разговор, в котором участники делятся различными юзкейсами из наших реальных проблем и анализа проектных решений. Такой формат позволил нам:

• Вовлечь в этот процесс как можно больше людей.

• Уметь приводить примеры из всех областей R&D, а не только того, кто готовит контент.

Как структурировать архитектурную тему

Название темы

Ссылки:

• Определения

• Соответствующие DR

• Материалы для чтения

• Разное

Почему?:

Краткое однострочное объяснение мотивации

Когда -> Тогда (When -> Then) <вопрос 1>:

• Вопрос должен описывать высокоуровневый вопрос в теме

• Для каждого юзкейса, относящегося к вопросу, создайте When -> Then

• Добавьте примеры из существующих решений или существующего технического долга

Когда -> Тогда <вопрос 2>:

• Вопрос должен описывать высокоуровневый вопрос в теме

• Для каждого юзкейса, относящегося к вопросу, создайте When -> Then

• Добавьте примеры из существующих решений или существующего технического долга

Мы создали шаблон

1. Релевантные ссылки

2. Краткое описание того, почему существует эта архитектурная тема

3. Список "когда->тогда"

• Каждая архитектурная тема может иметь один или несколько центральных вопросов

• Каждый вопрос будет начинаться со слова "когда".

• Каждый вопрос может иметь один или несколько "когда->тогда".

• Каждый "когда->тогда" представляет собой вариант использования в конкретном вопросе

Пример (с использованием определений ниже):

Название архитектурной темы — микросервисы с агрегированным и ограниченным контекстом.

Вопрос — когда создавать новый агрегированный микросервис?

"Когда->тогда" — когда "мы добавляем бизнес-юнит с командными (CRUD) операциями", тогда "рассмотрим возможность создания его как нового агрегированного микросервиса".

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

DDD по сравнению с микросервисами — логика или практика

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

Микросервис — это техническая имплементация, которая (надеюсь) реализует эти возможности:

• Высокое удобство сопровождения и тестируемость

• Свободная сочетаемость с другими микросервисами

• Высокая степень связности

• Возможность независимого развертывания

• Организован с учетом бизнес-возможностей

• Принадлежит небольшой команде

Например (используя определения, приведенные ниже), Агрегат (Aggregate) или Ограниченный Контекст (Bounded Context) являются производными от DDD. Это означает, что они являются логическими паттернами, вытекающими из моделирования нашего бизнеса, и мы можем представить агрегат как агрегированный микросервис, то же самое и для ограниченного контекста.

Основополагающие определения

Domain-Driven Design — "DDD" — это подход к проектированию программного обеспечения, который расшифровывается как предметно-ориентированное проектирование, сфокусированное на моделировании программного обеспечения для соответствия бизнес-домену согласно данных, полученных от экспертов этого домена. Целью DDD является улучшение коммуникации и структуры между различными областями знаний и создание общего языка, понятного всем членам вашей команды.

Ограниченный контекст (Bounded Context, BC) — это совокупность связанных областей\бизнес-требований\в нашем продукте. Каждая модель/бизнес-единица имеет конкретный смысл, который уникален и согласован в одном BC (единый язык). По мере развития нашего продукта рождается все больше BC. В DDD, BC содержит один или несколько агрегатов.

Агрегат (Aggregate) — это кластер связанных объектов, которые мы рассматриваем как единое целое при изменении данных. Его также часто называют бизнес-моделью.

View-Service (он же B.F.F. (Backend for Frontend)) — это централизованное место для реализации агрегации бизнес-логики и/или обогащения данных из одного или нескольких агрегатов, оптимизированных для функциональной области продукта (UI).

Сквозная функциональность (Cross-Cutting concern) обеспечивает широко используемые возможности для различных агрегатов в системе. Она не ориентирована на какую-либо определенную область продукции и должна поддерживать различные агрегаты для выполнения их повседневных задач.

Каналы связи (Communication Channels) — это способ взаимодействия между различными частями нашей системы. Связь может быть внутренней в пределах моего домена или внешней для других доменов, синхронной или асинхронной, извлекать данные только для чтения или изменять состояние данных.

Итак, что у нас получилось и что будет дальше

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

По сути, этот пост подводит итог нашей первой сессии из серии "Augurian architecture". Как вы уже догадались, впереди еще больше статей в блоге. Они будут посвящены конкретным архитектурным темам, которые мы сочли сложными, поскольку они неоднократно порождали открытые дискуссии и вызывали вопросы в наших проектных обзорах.

Как я уже писал выше "для чего мы оптимизируем наши руководства", с нашей точки зрения — это живые документы. Мы будем рады услышать, если у вас есть свои соображения по этим темам!

Приглашаем на открытый урок «Прошлое, настоящее и будущее роли Enterprise-Architect».

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

Записаться на урок можно на странице онлайн-курса "Enterprise Architect".