Domain-driven-design patterns for domain-driven microservice design, in UML notation
На тот случай, если кому-то в UML надо будет отобразить элементы DDD
source:https://ieeexplore.ieee.org/document/8354426
На тот случай, если кому-то в UML надо будет отобразить элементы DDD
source:https://ieeexplore.ieee.org/document/8354426
Микросервисы / распределенные системы
Декомпозиция наглядно.
По этой картинке необходимо пояснение.
Что здесь изображено?
По пунктам:
1. Существует бекенд, в котором сервисы Calculator и PartnerService зависят друг от друга неявным образом через сервис ContractService. То есть в изображенной структуре все зависят ото всех и изменения в любом из компонентов прямо или косвенно оказывает влияение на все 5 компонентов.
2. Посредством моделирования (этот процесс за скобками, можно использовать классический DDD, можно Event Storming, можно Domain Storytelling, да даже исходя из Business Capabilities) были определены границы и эти границы наложены на существующее решение. Мы видим на изображении, что Contract, Partner и ContractService по текущей внутренней реализации одновременно востребован и в контексте Sales и в контексте Risk Assessment.
3. Здесь изображеная целевая картинка, как может выглядеть декомпозиция. В Sales остается ContractService, в Risk Assessment остается PartnerService. Но остается вопрос: «а что делать с общей сущностью?». И ответ далеко не очевиден, потому что если посмотреть только на данные, то вроде как они нужны и там и там. Проблема в том, что зачастую в самих данных, в самих атрибутах нет метаданных об использовании этих атрибутов в тех или иных бизнес-операциях, контекстах, бизнес-процессах. Эту информацию приходится воссоздавать, чтобы определить какие данные в каком контексте какой смысл несут. Это важнейший аспект и как раз его нарушение ведет к появлению тех самых распределенных монолитов.
Как с этим быть?
4. В рамках моделирования и определения Ubiquitous Language (по сути языка, в котором каждый термин имеет однозначеное значение в заданной границе) мы выясняем, что в контексте Risk Assessment нет понятия signContract(), соответственно в этом контексте нет и термина для атрибута signatureDate. При этом исследуя Sales мы видим, что в этом контексте, контексте Продаж, нет понятия voteContract и в нем не определены термины ceditRating и votingResult. То есть здесь явным образом в одном сервисе и в одной сущности смешаны понятия из двух разных моделей. Негативное следствие этого – увеличение общей сложности, зависимости, размытие ответственности, ну и как следствие – подобная реализация сдерживает развитие каждой модели в отдельности. Что с этим делать?
Есть два варианта, безопасный и менее безопасный.
Безопасный показан на изображении:
5. Мы явно в рамках существующего сервиса делаем дубликат сущности Contract и сервиса ContractService и проводим рефакторинг внутри существующего сервиса. Например, это могут быть разные пакеты со своими интерфейсами.
6. В каждом из пакетов мы вычищаем то, что не относится к конкретному контексту, то есть проводим рефакторинг. Рефакторинг это ровно потому, что поведение не меняется, меняется только структура.
7. Получаем в рамках все того же монолита два пакетета, в рамках каждого из которых только сущности и методы, имеющие смысл в рамках определенного контекста.
Теперь о неточностях в изображении.
Возможно автор поторопился и есть нюанс, который вызывает вопросы, а именно, то, что на изображении (3) отсутствует сервис ContractService, хотя на последущих слайдах он указывает, что такой сервис существует. Это нисколько не меняет сути описанного подхода. Можно мысленно представить, что на изображении (3) есть еще один сервис ContractService, смысл не меняется совершенно, так как смысл ровно в том, каким образом разорвать зависимость.
Менее безопасный вариант:
Мы сразу выносим физически сервис ContractService в отдельный контекст, теперь у нас по инстансу ContractService в Sales и Risk Assessment, и проводим рефакторинг двух сервисов параллельно.
Что здесь изображено?
По пунктам:
1. Существует бекенд, в котором сервисы Calculator и PartnerService зависят друг от друга неявным образом через сервис ContractService. То есть в изображенной структуре все зависят ото всех и изменения в любом из компонентов прямо или косвенно оказывает влияение на все 5 компонентов.
2. Посредством моделирования (этот процесс за скобками, можно использовать классический DDD, можно Event Storming, можно Domain Storytelling, да даже исходя из Business Capabilities) были определены границы и эти границы наложены на существующее решение. Мы видим на изображении, что Contract, Partner и ContractService по текущей внутренней реализации одновременно востребован и в контексте Sales и в контексте Risk Assessment.
3. Здесь изображеная целевая картинка, как может выглядеть декомпозиция. В Sales остается ContractService, в Risk Assessment остается PartnerService. Но остается вопрос: «а что делать с общей сущностью?». И ответ далеко не очевиден, потому что если посмотреть только на данные, то вроде как они нужны и там и там. Проблема в том, что зачастую в самих данных, в самих атрибутах нет метаданных об использовании этих атрибутов в тех или иных бизнес-операциях, контекстах, бизнес-процессах. Эту информацию приходится воссоздавать, чтобы определить какие данные в каком контексте какой смысл несут. Это важнейший аспект и как раз его нарушение ведет к появлению тех самых распределенных монолитов.
Как с этим быть?
4. В рамках моделирования и определения Ubiquitous Language (по сути языка, в котором каждый термин имеет однозначеное значение в заданной границе) мы выясняем, что в контексте Risk Assessment нет понятия signContract(), соответственно в этом контексте нет и термина для атрибута signatureDate. При этом исследуя Sales мы видим, что в этом контексте, контексте Продаж, нет понятия voteContract и в нем не определены термины ceditRating и votingResult. То есть здесь явным образом в одном сервисе и в одной сущности смешаны понятия из двух разных моделей. Негативное следствие этого – увеличение общей сложности, зависимости, размытие ответственности, ну и как следствие – подобная реализация сдерживает развитие каждой модели в отдельности. Что с этим делать?
Есть два варианта, безопасный и менее безопасный.
Безопасный показан на изображении:
5. Мы явно в рамках существующего сервиса делаем дубликат сущности Contract и сервиса ContractService и проводим рефакторинг внутри существующего сервиса. Например, это могут быть разные пакеты со своими интерфейсами.
6. В каждом из пакетов мы вычищаем то, что не относится к конкретному контексту, то есть проводим рефакторинг. Рефакторинг это ровно потому, что поведение не меняется, меняется только структура.
7. Получаем в рамках все того же монолита два пакетета, в рамках каждого из которых только сущности и методы, имеющие смысл в рамках определенного контекста.
Теперь о неточностях в изображении.
Возможно автор поторопился и есть нюанс, который вызывает вопросы, а именно, то, что на изображении (3) отсутствует сервис ContractService, хотя на последущих слайдах он указывает, что такой сервис существует. Это нисколько не меняет сути описанного подхода. Можно мысленно представить, что на изображении (3) есть еще один сервис ContractService, смысл не меняется совершенно, так как смысл ровно в том, каким образом разорвать зависимость.
Менее безопасный вариант:
Мы сразу выносим физически сервис ContractService в отдельный контекст, теперь у нас по инстансу ContractService в Sales и Risk Assessment, и проводим рефакторинг двух сервисов параллельно.
Микросервисы / распределенные системы
Декомпозиция наглядно.
/// продолжение
В чем тут потенциальные проблемы?
- Двойные усилия, – параллельно из двух сервисов вычищается ненужный код
- Цена ошибки, – если мы допустили ошибку в определении места того или иного понятия, то в рамках единой кодовой базы мы просто перебросим код средствами IDE, если же это разные сервисы, то нужно будет перекидывать логику из одного сервиса в другой, физически из одного репозитория в другой. Если вспомнить, что сервисы не живут в изоляции, то нужно будет перенести и тестовые сценарии, а возможно и изменить какие-то внешние интерфейсы. Это очень дорого.
- Миграция данных, – опять же, следствие физического разграничения, – нужно будет не только бизнес-логику передать в другой сервис, но и физически мигрировать данные, а это могут быть в принципе даже совершенно разные базы данных (PG и Mongo, например).
Вывод
Несмотря на то, что изображение действительно может вызвать неоднозначное толкование, процесс на нем показан корректный с точки зрения иллюстрации того, каким образом происходит разрыв зависимостей на уровне предметной области, а именно, – устранение множественных, несовместимых на уровне моделей/контекстов, ответственностей и атрибутов. Несовместимых здесь означает, что есть одна сущность, например Contract, используется в двух моделях и в каждой из моделей у этой сущности есть атрибуты или поведение, которые не определены в этой модели или имеют собственное определение в каждой из моделей. Последнее означает, что каждая модель использует атрибут по-своему в своем контексте и изменения в одной модели могут привести (и часто приводят) к некорректному поведению в другой модели.
Надеюсь, что после этого пояснения станет немного понятнее, спасибо за внимание 🙂
PS: сама презентация: https://speakerdeck.com/hschwentner/domain-driven-transformation
В чем тут потенциальные проблемы?
- Двойные усилия, – параллельно из двух сервисов вычищается ненужный код
- Цена ошибки, – если мы допустили ошибку в определении места того или иного понятия, то в рамках единой кодовой базы мы просто перебросим код средствами IDE, если же это разные сервисы, то нужно будет перекидывать логику из одного сервиса в другой, физически из одного репозитория в другой. Если вспомнить, что сервисы не живут в изоляции, то нужно будет перенести и тестовые сценарии, а возможно и изменить какие-то внешние интерфейсы. Это очень дорого.
- Миграция данных, – опять же, следствие физического разграничения, – нужно будет не только бизнес-логику передать в другой сервис, но и физически мигрировать данные, а это могут быть в принципе даже совершенно разные базы данных (PG и Mongo, например).
Вывод
Несмотря на то, что изображение действительно может вызвать неоднозначное толкование, процесс на нем показан корректный с точки зрения иллюстрации того, каким образом происходит разрыв зависимостей на уровне предметной области, а именно, – устранение множественных, несовместимых на уровне моделей/контекстов, ответственностей и атрибутов. Несовместимых здесь означает, что есть одна сущность, например Contract, используется в двух моделях и в каждой из моделей у этой сущности есть атрибуты или поведение, которые не определены в этой модели или имеют собственное определение в каждой из моделей. Последнее означает, что каждая модель использует атрибут по-своему в своем контексте и изменения в одной модели могут привести (и часто приводят) к некорректному поведению в другой модели.
Надеюсь, что после этого пояснения станет немного понятнее, спасибо за внимание 🙂
PS: сама презентация: https://speakerdeck.com/hschwentner/domain-driven-transformation
Очень интересный ресурс, для общего развития «40 maps that explain the internet»
https://www.vox.com/a/internet-maps
https://www.vox.com/a/internet-maps
vox.com
40 maps that explain the internet
The internet increasingly pervades our lives, delivering information to us no matter where we are. It takes a complex system of cables, servers, towers, and other infrastructure, developed over decades, to allow us to stay in touch with our friends and family…
Пошел удивительный тренд (впервые был замечен на хабре), что микросервисы – это не распределенная система (а земля, видимо, все-таки плоская). Достаточно взять определение Таненбаума: «Распределенная система — это набор независимых компьютеров, представляющийся их пользователям единой объединенной системой. В этом определении оговариваются два момента. Первый относится к аппаратуре: все машины автономны. Второй касается программного обеспечения: пользователи думают, что имеют дело с единой системой.»
Если так подумать, то у нас сейчас практически любая система – распределенная система :)
Но что касается микросервисов, – это не просто распределенная система, у этого архитектурного стиля есть ряд важных особенностей, а именно в микросервисном архитектурном стиле должна быть обеспечена:
- Независимость на уровне моделей предметных областей, что дает независимое, но в то же время полное понимание отдельно взятого микросервиса
- Возможность одновременного сосуществование нескольких версий одного сервиса
- Независимое эволюционное развитие за счет сокрытия внутренней реализации (независимая реализация, независимое развертываение, независимое тестирование, независимая возможность выбора используемых технологий)
- Изоляция сбоев на уровне отдельных микросервисов
- При необходимости – изменение топологии в режиме реального времени
- Отдельный микросервис может быть изменен без влияния на работу других микросервисов
Это свойства микросервисного архитектурного стиля, если какие-то свойства не заложены, то это не микросервисный архитектурный стиль. Поэтому, когда вам говорят или вы слышите на конференциях, что «один микросервис упал и все сломалось», «сложно провести полный регресс всех микросервисов», «необходимость внесения изменений во всех микросервисах для реализации одной фичи приводит к тому, что нельзя зарелизить ничего, пока все не сделают», – это про какой-то другой архитектурный стиль и на самом деле такие выступления в большей степени указывают не на недостатки микросервисов, а на то, что пишут или рассказывают про что-то другое.
Это равнозначно, что сказать - борщ - это фигня и рассказывать про вермишелевый суп. Вроде суп, но ведь не тот же :)
Микросервисы - это совсем не просто. Это большая и сложная работа как раз потому, что включает в себя и околостоящие инженерные практики и изменение процессов и порой смену самой парадигмы разработки. Нередко с моего курса по микросервисам уходят с осознанием, что вроде как они и не нужны в конкретном проекте.
Не бывает правильных или неправильных архитектурных решений, бывают подходящие и не подходящие и если пихать везде что-то из-за хайпа, то где-то оно покажет хороший результат, но это будет, скорее случайность, чем осознанный выбор.
Если так подумать, то у нас сейчас практически любая система – распределенная система :)
Но что касается микросервисов, – это не просто распределенная система, у этого архитектурного стиля есть ряд важных особенностей, а именно в микросервисном архитектурном стиле должна быть обеспечена:
- Независимость на уровне моделей предметных областей, что дает независимое, но в то же время полное понимание отдельно взятого микросервиса
- Возможность одновременного сосуществование нескольких версий одного сервиса
- Независимое эволюционное развитие за счет сокрытия внутренней реализации (независимая реализация, независимое развертываение, независимое тестирование, независимая возможность выбора используемых технологий)
- Изоляция сбоев на уровне отдельных микросервисов
- При необходимости – изменение топологии в режиме реального времени
- Отдельный микросервис может быть изменен без влияния на работу других микросервисов
Это свойства микросервисного архитектурного стиля, если какие-то свойства не заложены, то это не микросервисный архитектурный стиль. Поэтому, когда вам говорят или вы слышите на конференциях, что «один микросервис упал и все сломалось», «сложно провести полный регресс всех микросервисов», «необходимость внесения изменений во всех микросервисах для реализации одной фичи приводит к тому, что нельзя зарелизить ничего, пока все не сделают», – это про какой-то другой архитектурный стиль и на самом деле такие выступления в большей степени указывают не на недостатки микросервисов, а на то, что пишут или рассказывают про что-то другое.
Это равнозначно, что сказать - борщ - это фигня и рассказывать про вермишелевый суп. Вроде суп, но ведь не тот же :)
Микросервисы - это совсем не просто. Это большая и сложная работа как раз потому, что включает в себя и околостоящие инженерные практики и изменение процессов и порой смену самой парадигмы разработки. Нередко с моего курса по микросервисам уходят с осознанием, что вроде как они и не нужны в конкретном проекте.
Не бывает правильных или неправильных архитектурных решений, бывают подходящие и не подходящие и если пихать везде что-то из-за хайпа, то где-то оно покажет хороший результат, но это будет, скорее случайность, чем осознанный выбор.
В продолжение предыдущего поста. Вообще, в нашей индустрии, много проблем, связанных с поверхностным пониманием тех или иных технологий, подходов.
Оно и не мудрено, - индустрия молодая, даже в фундаментальных аспектах эксперты порой расходятся во мнениях.
Стандарты есть, конечно, но стандарты не сказать, чтобы были стандартами индустрии, - кто-то воспринимает и использует, кто-то даже не слышал. А вот интерпретаций без отсылок к первоисточникам сколько угодно.
Ну а работать как-то надо, вот и приходится раскапывать по крупицам хоть что-то.
Если взять ту же микросервисную архитектуру. Я уже упоминал, что мне здесь немного повезло, был проект почти 20 лет назад, в котором мы реализовали как раз то, что сейчас называется микросервисной архитектурой. В том же проекте был реализован Event Sourcing, хотя я в то время даже слова такого не слышал.
И я такой был 100% не один, уверен, что реализаций были сотни, тысячи. И микросервисный стиль никто не придумывал, он уже был, активно использовался, применялся, этому стилю всего лишь дали имя и попытались описать характеристики.
Термин получился может и не самый удачный для описания сути, но максимально хайповый, тут не отнять. Характеристики тоже попытались описать, получилось как получилось, попробуйте на досуге взять свое архитектурное решение и формализовать его характеристики для того, чтобы его можно было повторно использовать и развивать вокруг него теоретико-практическую базу. Этих характеристик будет практически бесконечное число, так что вам придется взять все существующие стили и выделить:
1. Те, что отличают от других
2. Те, что четко определяют ваш архитектурный стиль в своей совокупности
Я обобщаю и выделяю паттерны из конкретных сессий event storming и это максимально неблагодарное занятие.
Вернемся к описанию архитектурного стиля и вспомним фундаментальные труды по архитектуре. Как там описаны стили? Текстом в свободной форме. Какой-то формализм, конечно, присутствует, но в целом «что вижу - то описываю». Проблема здесь в том, что даже если трое видят одно и то же, описать они это могут совершенно по-разному. А те, кто прочитают, каждый кто прочитает, - могут и понять по-своему и написать по статье на хабре или медиуме со своим понимаем, и вот у нас уже 100500 интерпретаций.
Ситуация ухудшается, когда нечто на хайпе, - статей и интерпретаций становится настолько много, что с ума можно сойти.
У меня, конечно, есть четкое понимание, что такое микросервисный архитектурный стиль, какие ему присущи свойства, но когда начинаешь об этом писать или говорить, то буквально каждое слово приходится раскрывать, чтобы не быть неправильно понятым, а за некоторыми словами или терминами целая отдельная огромная предметная область.
Например, банальное «изоляция сбоев на уровне отдельных микросервисов». Мало того, что здесь смешаны и технические сбои и бизнес-ориентированные, так тут еще и что такое изоляция, а дальше, - как идентифицировать сбой, как его обработать, различные виды деградации, определение корректирующих действий, мониторинг…. В общем, не все так просто, как кажется на первый взгляд при прочтении нескольких слов, а стандартов описания нет, вот мы и живем каждый в своем контексте, но даже не смотря на это умудряемся строить надежные, эффективные, полезные, быстрые решения :)
Оно и не мудрено, - индустрия молодая, даже в фундаментальных аспектах эксперты порой расходятся во мнениях.
Стандарты есть, конечно, но стандарты не сказать, чтобы были стандартами индустрии, - кто-то воспринимает и использует, кто-то даже не слышал. А вот интерпретаций без отсылок к первоисточникам сколько угодно.
Ну а работать как-то надо, вот и приходится раскапывать по крупицам хоть что-то.
Если взять ту же микросервисную архитектуру. Я уже упоминал, что мне здесь немного повезло, был проект почти 20 лет назад, в котором мы реализовали как раз то, что сейчас называется микросервисной архитектурой. В том же проекте был реализован Event Sourcing, хотя я в то время даже слова такого не слышал.
И я такой был 100% не один, уверен, что реализаций были сотни, тысячи. И микросервисный стиль никто не придумывал, он уже был, активно использовался, применялся, этому стилю всего лишь дали имя и попытались описать характеристики.
Термин получился может и не самый удачный для описания сути, но максимально хайповый, тут не отнять. Характеристики тоже попытались описать, получилось как получилось, попробуйте на досуге взять свое архитектурное решение и формализовать его характеристики для того, чтобы его можно было повторно использовать и развивать вокруг него теоретико-практическую базу. Этих характеристик будет практически бесконечное число, так что вам придется взять все существующие стили и выделить:
1. Те, что отличают от других
2. Те, что четко определяют ваш архитектурный стиль в своей совокупности
Я обобщаю и выделяю паттерны из конкретных сессий event storming и это максимально неблагодарное занятие.
Вернемся к описанию архитектурного стиля и вспомним фундаментальные труды по архитектуре. Как там описаны стили? Текстом в свободной форме. Какой-то формализм, конечно, присутствует, но в целом «что вижу - то описываю». Проблема здесь в том, что даже если трое видят одно и то же, описать они это могут совершенно по-разному. А те, кто прочитают, каждый кто прочитает, - могут и понять по-своему и написать по статье на хабре или медиуме со своим понимаем, и вот у нас уже 100500 интерпретаций.
Ситуация ухудшается, когда нечто на хайпе, - статей и интерпретаций становится настолько много, что с ума можно сойти.
У меня, конечно, есть четкое понимание, что такое микросервисный архитектурный стиль, какие ему присущи свойства, но когда начинаешь об этом писать или говорить, то буквально каждое слово приходится раскрывать, чтобы не быть неправильно понятым, а за некоторыми словами или терминами целая отдельная огромная предметная область.
Например, банальное «изоляция сбоев на уровне отдельных микросервисов». Мало того, что здесь смешаны и технические сбои и бизнес-ориентированные, так тут еще и что такое изоляция, а дальше, - как идентифицировать сбой, как его обработать, различные виды деградации, определение корректирующих действий, мониторинг…. В общем, не все так просто, как кажется на первый взгляд при прочтении нескольких слов, а стандартов описания нет, вот мы и живем каждый в своем контексте, но даже не смотря на это умудряемся строить надежные, эффективные, полезные, быстрые решения :)
Domain Driven Cloud
Естественное продолжение идей разграничения ответственностей на уровне моделей. Конечно, все сыренько пока, посмотрим, перейдет во что-то серьезное или нет.
https://www.infoq.com/articles/domain-driven-cloud/
Естественное продолжение идей разграничения ответственностей на уровне моделей. Конечно, все сыренько пока, посмотрим, перейдет во что-то серьезное или нет.
https://www.infoq.com/articles/domain-driven-cloud/
InfoQ
Domain-Driven Cloud: Aligning Your Cloud Architecture to Your Business Model
Domain-Driven Cloud (DDC) is an approach for creating your organization’s cloud architecture based on your business model. Based on Domain-Driven Design (DDD) and the architecture principle of high cohesion and low coupling, this article introduces DDC including…
Please open Telegram to view this post
VIEW IN TELEGRAM
В статье достаточно структурно изложены основные области знаний, которые имеет смысл подтянуть при движении от разработчика к Solution Architect.
From developer to (solutions) architect. A simple guide.
https://dev.to/this-is-learning/from-developer-to-solutions-architect-a-simple-guide-2b91
From developer to (solutions) architect. A simple guide.
https://dev.to/this-is-learning/from-developer-to-solutions-architect-a-simple-guide-2b91
Forwarded from Russian Association of Software Architects (Sergey Baranov)
Вы, как архитектор, ставите задачи разработчикам/формируете беклог
Anonymous Poll
29%
Да
14%
Нет
57%
Я не архитектор, посмотреть ответы
Микросервисы / распределенные системы
Вы, как архитектор, ставите задачи разработчикам/формируете беклог
Краткая выжимка моих ответов из обсуждения этой темы.
Определения:
PBI - элемент беклога (очередь задач на выполнение).
У каждого PBI должна быть бизнес-ценность, а элементы беклога выстраиваются в порядке максимизации бизнес-ценности.
Обсуждение началось с понятия «техническая таска», которыми могут быть enabler, spike, acceptance criteria.
Важно отметить, что:
Enabler всегда привязан к story/epic, он enabler для этого PBI, поэтому наследует бизнес-ценность этого PBI.
Acceptance criteria - это свойство pbi, определяется как часть pbi, у которого определена бизнес-ценность.
Spike - это предусловие для pbi и наследует бизнес-ценность pbi.
Не важно что за pbi рассматривается, - бизнес-ценность должна быть и она должна быть сводимой к некоторой цели, иначе невозможно выставить приоритеты.
Если архитектор ставит задачи команде в обход PO (например по квотам) - это дисфункция, так как квотирование означает, что бизнес-ценность по каким-то причинам не может быть донесена. Бизнес-ценность при этом может быть определена на уровне продукта, компании, группы компаний.
Таким образом, техническая задача или нет - совершенно не важно, если есть возможность определить ее бизнес-ценность и выразить ее. Невозможность определить бизнес-ценность говорит либо о том, что ее нет, либо о том, что есть нехватка контекста/знаний/опыта для ее определения.
Что делать с техническими задачами вида «настроить CI/CD»?
Это не техническая задача, это своего рода операционная деятельность команды и она вполне выражается в бизнес-ценности, но не на уровне бизнес-ценности продукта. Есть определенные метрики, просадка которых грозит бизнесу банкротством, как например, снижение скорости развития (и сразу конкуренты обошли на повороте). Успешная настройка CI/CD будет обладать высокой бизнес-ценностью для команды, для которой внутренним продуктом является как раз развертывание CI/CD командам.
Аналогия с хирургией. В хирургии беклог – это пациенты, ранжированные по степени тяжести состояния. Никто в этот беклог не поместит «кипячение инструмента», «подготовку баллона с кислородом», «дезинфекцию операционной», «покупку новой лампы». Если эти важные, инфраструктурные процессы будут проседать, – инструмент закончится, пациенты будут умирать от заражений, не будут дожидаться своей очереди и так далее, это как раз и есть проблема сопуствующих, поддерживающих процессов.
Хирург в общем случае не моет пол и не катает тележку с пациентом. Не, он, конечно может, но тогда число пациентов, которым он может провести операцию, сократиться (то есть число выполненных бизнес-задач из беклога).
В Team Topologies предложили решение, которое мы практикуем уже лет 20 даже на моей памяти, они его скорее формализовали, – enabling team. Ты должен уметь пользоваться инструментом, но следить за его работоспособностью будут другие люди. Тебе поставят, развернут и настроят CI/CD, но ты обязан уметь пользоваться этим инструментарием, это твой условный скальпель.
Другой класс задач – это архитектурные изменения. Например, в компании перепиливается архитектура, чтобы обеспечить надежность в пять девяток и сделать публичной статистику uptime. Технических изменений много, но они все несут бизнес-ценность, а бизнес-ценность в том, чтобы изменить свою конкурентную позицию на рынке, – брать клиентов высокой надежностью. Это рациональное, взвешанное бизнес-решение, на текущий момент уже год идут изменения и каждый архитектор, PO и разработчик понимает какие конкретно это несет выгоды для бизнеса и почему это важно именно сейчас.
Определения:
PBI - элемент беклога (очередь задач на выполнение).
У каждого PBI должна быть бизнес-ценность, а элементы беклога выстраиваются в порядке максимизации бизнес-ценности.
Обсуждение началось с понятия «техническая таска», которыми могут быть enabler, spike, acceptance criteria.
Важно отметить, что:
Enabler всегда привязан к story/epic, он enabler для этого PBI, поэтому наследует бизнес-ценность этого PBI.
Acceptance criteria - это свойство pbi, определяется как часть pbi, у которого определена бизнес-ценность.
Spike - это предусловие для pbi и наследует бизнес-ценность pbi.
Не важно что за pbi рассматривается, - бизнес-ценность должна быть и она должна быть сводимой к некоторой цели, иначе невозможно выставить приоритеты.
Если архитектор ставит задачи команде в обход PO (например по квотам) - это дисфункция, так как квотирование означает, что бизнес-ценность по каким-то причинам не может быть донесена. Бизнес-ценность при этом может быть определена на уровне продукта, компании, группы компаний.
Таким образом, техническая задача или нет - совершенно не важно, если есть возможность определить ее бизнес-ценность и выразить ее. Невозможность определить бизнес-ценность говорит либо о том, что ее нет, либо о том, что есть нехватка контекста/знаний/опыта для ее определения.
Что делать с техническими задачами вида «настроить CI/CD»?
Это не техническая задача, это своего рода операционная деятельность команды и она вполне выражается в бизнес-ценности, но не на уровне бизнес-ценности продукта. Есть определенные метрики, просадка которых грозит бизнесу банкротством, как например, снижение скорости развития (и сразу конкуренты обошли на повороте). Успешная настройка CI/CD будет обладать высокой бизнес-ценностью для команды, для которой внутренним продуктом является как раз развертывание CI/CD командам.
Аналогия с хирургией. В хирургии беклог – это пациенты, ранжированные по степени тяжести состояния. Никто в этот беклог не поместит «кипячение инструмента», «подготовку баллона с кислородом», «дезинфекцию операционной», «покупку новой лампы». Если эти важные, инфраструктурные процессы будут проседать, – инструмент закончится, пациенты будут умирать от заражений, не будут дожидаться своей очереди и так далее, это как раз и есть проблема сопуствующих, поддерживающих процессов.
Хирург в общем случае не моет пол и не катает тележку с пациентом. Не, он, конечно может, но тогда число пациентов, которым он может провести операцию, сократиться (то есть число выполненных бизнес-задач из беклога).
В Team Topologies предложили решение, которое мы практикуем уже лет 20 даже на моей памяти, они его скорее формализовали, – enabling team. Ты должен уметь пользоваться инструментом, но следить за его работоспособностью будут другие люди. Тебе поставят, развернут и настроят CI/CD, но ты обязан уметь пользоваться этим инструментарием, это твой условный скальпель.
Другой класс задач – это архитектурные изменения. Например, в компании перепиливается архитектура, чтобы обеспечить надежность в пять девяток и сделать публичной статистику uptime. Технических изменений много, но они все несут бизнес-ценность, а бизнес-ценность в том, чтобы изменить свою конкурентную позицию на рынке, – брать клиентов высокой надежностью. Это рациональное, взвешанное бизнес-решение, на текущий момент уже год идут изменения и каждый архитектор, PO и разработчик понимает какие конкретно это несет выгоды для бизнеса и почему это важно именно сейчас.
Микросервисы / распределенные системы
Вы, как архитектор, ставите задачи разработчикам/формируете беклог
//продолжение
Далее Иван справедливо заметил: «если есть enabling/platform team, то ряд вопросов обретает совсем другой окрас.».
Конечно, Ваня полностью прав, ну а если нет такой enabling/platform team, то у тебя одна физическая команда поделена на две логические и это тот еще ад. Тот самый условный хирург еще и инструмент моет, пол моет, закупами медикаментов занимается, каталку катает и так далее. Аналогия один-в-один.
Можно накидать в беклог задач, вроде:
- заплатить налоги
- заплатить пенсионные взносы
- подготовить договор с заказчиком
- подготовить закрывающие документы
- арендовать землю под подстройку второго офиса
- починить принтер
…
Но вот тут что-то вопросов не возникает. Это важные для функционирования бизнеса задачи и под них люди есть. В разработке ведь точно так же, – есть важные для возможности эффективной разработки задачи, обеспечивающие задачи.
Какой из этого можно сделать вывод?
В контексте продукта чисто технических задач не должно быть, они все должны быть привязаны к успеху продукта в том или ином виде. Если для конкретной задачи не удается определить бизнес-ценность, то либо ее нет, либо пока не удалось определить, либо она где-то в другом месте.
Далее Иван справедливо заметил: «если есть enabling/platform team, то ряд вопросов обретает совсем другой окрас.».
Конечно, Ваня полностью прав, ну а если нет такой enabling/platform team, то у тебя одна физическая команда поделена на две логические и это тот еще ад. Тот самый условный хирург еще и инструмент моет, пол моет, закупами медикаментов занимается, каталку катает и так далее. Аналогия один-в-один.
Можно накидать в беклог задач, вроде:
- заплатить налоги
- заплатить пенсионные взносы
- подготовить договор с заказчиком
- подготовить закрывающие документы
- арендовать землю под подстройку второго офиса
- починить принтер
…
Но вот тут что-то вопросов не возникает. Это важные для функционирования бизнеса задачи и под них люди есть. В разработке ведь точно так же, – есть важные для возможности эффективной разработки задачи, обеспечивающие задачи.
Какой из этого можно сделать вывод?
В контексте продукта чисто технических задач не должно быть, они все должны быть привязаны к успеху продукта в том или ином виде. Если для конкретной задачи не удается определить бизнес-ценность, то либо ее нет, либо пока не удалось определить, либо она где-то в другом месте.
Через минуту стартуем митап
«Тернистый путь инструмента цифрового проектирования».
Спикер: Виктор Выскребенцев — Исполнительный директор в ПАО Сбербанк.
Yotube-трансляция: https://www.youtube.com/live/jP_AROux7Fs?feature=shared
(запись доступна по этой же ссылке)
«Тернистый путь инструмента цифрового проектирования».
Спикер: Виктор Выскребенцев — Исполнительный директор в ПАО Сбербанк.
Yotube-трансляция: https://www.youtube.com/live/jP_AROux7Fs?feature=shared
(запись доступна по этой же ссылке)
YouTube
Тернистый путь инструмента цифрового проектирования. Виктор Выскребенцев
Митап в рамках конференции ARCHDAYS: https://archconf.ru/arch
Ссылка на упоминаемое в выступлении видео.
Governance as a code: как соблюдать стандарты разработки и не тормозить доставку фич/ Александр Токарев
https://www.youtube.com/watch?v=lirtDkCIeXA
Ссылка на упоминаемое в выступлении видео.
Governance as a code: как соблюдать стандарты разработки и не тормозить доставку фич/ Александр Токарев
https://www.youtube.com/watch?v=lirtDkCIeXA
Нашел у себя план архитектурного кикофа (совместное формирование первичного видения архитектуры), Last edit was about 8 years ago 🙂
Зачем мы здесь собрались?
Просто и четко опишите проблему, которую намереваетесь решить.
Каково видение?
Опишите, как предлагаемый продукт решает ранее описанную проблему.
В чем ценность?
Опишите бизнес-ценности продукта.
Каков скоуп?
Перечислите наиболее приоритетные из уже известных функциональные требования. Обычно — это must have фичи.
Перечислите то, что не входит в скоуп.
Какие фичи могут повлиять на архитектурное решение?
Кто ключевые заинтересованные лица?
Перечислите заинтересованных лиц и их основной интерес
Как выглядит наиболее просто решение?
Скетч номинальной архитектуры. Это может быть неформальная диаграмма.
Каковы ключевые риски?
Перечислить топ ключевых рисков.
Как много предстоит сделать? Какова стоимость?
Имея на руках предварительные данные по скоупу и номинальную архитектуру, оцените приблизительные затраты и стоимость реализации. Перечислите предположения, касающиеся размера команды и уровня компетений.
Каковы ожидания по компромиссам?
Обсудите ключевые компромиссы прежде чем переходить к принятию сложных решений. Обсудите большую четверку: стоимость, скоуп, сроки и качество. Обсудите важные атрибуты качества.
Когда будет готово?
Предоставьте стейкхолдерам идеи о том, сколько времени может занять разработка продукта. Оценка позволяет начать разговор об основных вехах разработки продукта. Создайте черновик таймлана для известных видов работ. Таймлайн не обязан быть точным и может изменяться по мере работы над продуктом.
Зачем мы здесь собрались?
Просто и четко опишите проблему, которую намереваетесь решить.
Каково видение?
Опишите, как предлагаемый продукт решает ранее описанную проблему.
В чем ценность?
Опишите бизнес-ценности продукта.
Каков скоуп?
Перечислите наиболее приоритетные из уже известных функциональные требования. Обычно — это must have фичи.
Перечислите то, что не входит в скоуп.
Какие фичи могут повлиять на архитектурное решение?
Кто ключевые заинтересованные лица?
Перечислите заинтересованных лиц и их основной интерес
Как выглядит наиболее просто решение?
Скетч номинальной архитектуры. Это может быть неформальная диаграмма.
Каковы ключевые риски?
Перечислить топ ключевых рисков.
Как много предстоит сделать? Какова стоимость?
Имея на руках предварительные данные по скоупу и номинальную архитектуру, оцените приблизительные затраты и стоимость реализации. Перечислите предположения, касающиеся размера команды и уровня компетений.
Каковы ожидания по компромиссам?
Обсудите ключевые компромиссы прежде чем переходить к принятию сложных решений. Обсудите большую четверку: стоимость, скоуп, сроки и качество. Обсудите важные атрибуты качества.
Когда будет готово?
Предоставьте стейкхолдерам идеи о том, сколько времени может занять разработка продукта. Оценка позволяет начать разговор об основных вехах разработки продукта. Создайте черновик таймлана для известных видов работ. Таймлайн не обязан быть точным и может изменяться по мере работы над продуктом.
Еще из старого:
«Bounded Context» как решение проблем с аморфными терминами через контекстные границы доменных моделей
Если нужна информация из ограниченного контекста или нужно сделать запросы на какие-либо действия внутри ограниченного контекста, происходит обмен данными с его четко обозначенной границей с помощью моделей.
Приступая к обдумыванию ограниченных контекстов, имеющихся в вашей организации, нужно размышлять не в понятиях совместно используемых данных, а в понятиях возможностей, предоставляемых такими контекстами всей остальной предметной области.
«Bounded Context» как решение проблем с аморфными терминами через контекстные границы доменных моделей
Если нужна информация из ограниченного контекста или нужно сделать запросы на какие-либо действия внутри ограниченного контекста, происходит обмен данными с его четко обозначенной границей с помощью моделей.
Приступая к обдумыванию ограниченных контекстов, имеющихся в вашей организации, нужно размышлять не в понятиях совместно используемых данных, а в понятиях возможностей, предоставляемых такими контекстами всей остальной предметной области.
Объемная статья про практики распределенной трассировки.
https://www.zerok.ai/post/distributed-tracing-best-practices
https://www.zerok.ai/post/distributed-tracing-best-practices
А админ-то прав 🙂
В сложных системах, состоящих из множества компонентов (+инфраструктурных) и инстансов этих компонентов, среднее время между сбоями (MTBF) стремится к нулю. В любой момент времени что-то может упасть, лежать или деплоится.
Во-первых, в такой ситуации важно не накопить критическую массу отказов, при которой вся система умрет.
Во-вторых, в таких системах точно известно, что отказы неизбежны, но неизвестно что конкретно и когда откажет.
Вот поэтому и нужно уметь поднимать быстро :)
В сложных системах, состоящих из множества компонентов (+инфраструктурных) и инстансов этих компонентов, среднее время между сбоями (MTBF) стремится к нулю. В любой момент времени что-то может упасть, лежать или деплоится.
Во-первых, в такой ситуации важно не накопить критическую массу отказов, при которой вся система умрет.
Во-вторых, в таких системах точно известно, что отказы неизбежны, но неизвестно что конкретно и когда откажет.
Вот поэтому и нужно уметь поднимать быстро :)