Прежде чем мы начнем — этот пост в блоге написала я, искренне ваша Хила (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
Добавьте примеры из существующих решений или существующего технического долга
Мы создали шаблон
Релевантные ссылки
Краткое описание того, почему существует эта архитектурная тема
Список "когда->тогда"
Каждая архитектурная тема может иметь один или несколько центральных вопросов
Каждый вопрос будет начинаться со слова "когда".
Каждый вопрос может иметь один или несколько "когда->тогда".
Каждый "когда->тогда" представляет собой вариант использования в конкретном вопросе
Пример (с использованием определений ниже):
Название архитектурной темы — микросервисы с агрегированным и ограниченным контекстом.
Вопрос — когда создавать новый агрегированный микросервис?
"Когда->тогда" — когда "мы добавляем бизнес-юнит с командными (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".
joffer
в очередной раз про DDD и в очередной раз непонятно
можно простыми словами, для глупых?
что такое DDD, в чём суть?
Какой ещё общий язык, понятный всем членам команды? English, bug-tracker, task-tracker - вот наш язык.
Цель - улучшение коммуникации между различными областями знаний - типа более продвинутое, гибкое API или что зашифровано здесь?
вот у нас есть OOP (ООП) - подход, когда наш код разделён на объекты, которые задаются классами, которые должны обеспечивать контракты (имплементировать интерфейс) или просто быть написаны как святой пирог на душу положил.
Соответственно, вот у нас раньше было куча кода в 5ти файлах, например, это php или js
И вот мы взяли и переписали их в ООП-парадигме - поделив и представив весь код в виде классов, по которым в ран-тайме будет варить объекты. Мы получили вместо 5 файлов условно 200, но каждый файл представляет какой-то класс, по которому инстанциируется его объект - ну и дальше уже там объекты взаимодействуют между собой, реализуя бизнес логику.
Так вот.
Где. В каком месте. Как. Подключается в вот эту модель DDD? Что нужно сделать с вот этим кодом, чтобы вышло DDD? какой даст профит?
То есть, мы как-то делим код на предметы/домены? Проектирование, сфокусированное на моделировании для соответствия бизнес-домену -- что такое бизнес-домен? Что это за данные, полученные от экспертов домена? Эксперты домена - это просто пользователи? Бизнес-домен - это какой-то кусок чего-то, бизнеса, сервиса, как его определить? Это корзина в интернет-магазине? Это какой-то сервис в мобильном телефоне? Возможно "забронировать" билет?
И как вы поняли, что пора в DDD? Вот как-то же был до того продукт/сервис/сайт, и вот он как-то проектировался архитекторами по хотелкам овнеров/аналитиков, окей - это и были эксперты домена? Или если не они, то кто новые таск-мейкеры?
Вот была у нас платформа, состояла из 50 микросервисов. Можно ли их переписать на DDD? Нужно ли? Как это понять? В чём суть?
Вот с ооп очень легко - если нужна единичная процедура, функция, скрипт, хело-ворлд какой-то - берёшь и пишешь просто код в скрипте. Затем кода становится много, что-то можно вынести в класс, который станет ответственным за какие-то объединённые общими операциями вещи.
Просто в очередной раз вижу статью про DDD, написанную теми, кто практикует DDD для тех, кто уже архитектор или даже не знаю кого. Вот для джунов можно написать? Чтобы ты зашёл и такой - "ага, это - домен. Это - эксперт. В коде это выглядит вот так". Какие-то, может, UML-диаграммы нарисовать, хз
dprotopopov
Я тоже не понял о чём статья
когда-то очень давно были 2 концепции программирования Object-Oriented-Programming и Domain-Data-Driven
При DDD кажется описание модели должно было задаваться через регистрацию кучи параметров в виде данных для единообразного обработчика всех типов модели
При OOP описание модели задаётся через отдельные обработчики для каждой модели
Как-то так была основное отличие
Выжила концепция OOP - которой сейчас пользуются все и большинство языков программирования под эту идею заточено.
хотя гугление хабра даёт https://habr.com/ru/post/334126/
joffer
прочитал - но, к сожалению, тоже мало что понял. Оно как-то у них неясно откуда начинается и неясно куда уходит и через что. Ну, это, наверное, интересно читать тем, кто уже делает что-то такое же, но своё, но вот я, как не осознавший, что это за DDD, не могу въехать и "прохавать", в чём суть
например, я могу понять, в чём суть MVC или там TDD и скорее всего сяк-так я смогу это реализовать в коде. Функциональное программирование - тоже вроде понятно, меняем подход к построению функций, не везде применимо, но вроде понятно. Вот есть ещё REST - типа как тоже архитектурный стиль, у него там есть какие-то подходы, которые если выполнить, то API будет RESTful и получит какие-то свои бенефиты от такого подхода, в расширяемости там или ещё в чём
А как доходит до DDD - начинается какая-то мистика, какие-от модели, планирование, домены и эксперты, и вроде все практикуют, но донести простым языком не могут. По крайней мере, у меня не вышло понять.
Вот дадут мне проект, скажут - напиши код - я напишу код.
Попросят - сделай MVC. Ну, заморочусь, растасую
Попросят - сделай TDD. Тоже можно. Или там "хотим только plain sql" или тма "можно ORM" - на каждом таком шаге понятна суть, понятно, что даст этот подход или построение.
Но вот если попросят - сделай DDD - без понятия, как его начинать. Что должно быть доменом и может ли класс описывать домен - или нужно 10 классов или что это.