Сообщество системных архитекторов Райффайзенбанка при поддержке DDDEvotion провело открытый онлайн-митап 22 сентября. Узнали, как практики DDD помогают декомпозировать системы на микросервисы, а также познакомились с Rich Communication Services и его применением по принципам DDD.
О спикере: Разработкой ПО занимается уже больше 10 лет. На данный момент работает архитектором. Начинал с C++ и немного Delphi, потом полностью перешел на .NET и C#, чему очень рад. Сменил несколько предметных областей — от военной отрасли и энергетики нефтедобычи до банковского дела. Старается всегда придерживаться прагматичных подходов без крайностей. Работает с сервисными архитектурами и DDD.
О докладе: На протяжении 5 лет мы в компании в различных проектах используем практики DDD. Они помогают нам декомпозировать системы на микросервисы, находить общий язык с заказчиком, создавать приложения, которые не сопротивляются новым требованиям, а также поддерживать качественное общение внутри команды. При этом часто от применения предметно-ориентированного проектирования отказываются из-за того, что это методология без четких указаний, что и как делать.
В докладе я расскажу о нашем применении этого подхода, какие хорошие практики мы используем, какие ошибки допускали и какие выводы из этого сделали.
ПРЕЗЕНТАЦИЯ
О спикере: Руководитель направления в FunBox. Прошёл путь от инженера до CTO. Запускал новые продукты, а иногда новых мобильных операторов с нуля. Сейчас занимается разработкой продуктов для нативного IM-мессенджера мобильного оператора.
О докладе: Разработка для мобильных операторов – это пересечение разных предметных областей, “классических” и совсем новых. Что делать, если эти предметные области сложные и запутанные? Как быть, если для тебя, как для разработчика, эти предметные области – совершенно незнакомые? Разберёмся на примере Rich Communication Services.
RCS – это доступный абонентам из коробки нативный IM-мессенджер замена стандартного SMS-сервиса оператора с видео, интерактивом, геолокацией, групповыми чатами и другими возможностями. Причём это “всего лишь” один из сервисов, которые используют сеть IP Multimedia Subsystem оператора. В докладе я расскажу о практиках, которые мы используем для старта разработки в новых предметных областях. Подробно остановлюсь на том, как нам помогают принципы Domain-Driven Design.
Мы верим, что с помощью этих практик, команда может разобраться в чем угодно и нарастить необходимую экспертизу за короткий срок. Даже в разработке для мобильных операторов.
ПРЕЗЕНТАЦИЯ
О чем поговорили
Ответы на вопросы
Взаимодействие между агрегатами внутри одного микросервиса у вас как организовано? Агрегат хранит ссылку на другой агрегат, или агрегат хранит идентификатор другого агрегата, или же эвентами обходитесь? Если эвентами, то как механизм у вас организован?
Это очень сильно зависит от сервиса и времени его создания. 4 года назад мы допускали связывание агрегатов по ссылке, и не особо думали о концепции агрегатов вообще. Сейчас мы используем для связи агрегатов и идентификаторы (чаще для чтения), и события (для оповещения об изменениях). В новых системах в одном микросервисе живет только один агрегат, что автоматически приводит к отказу от прямых ссылок. По поводу событий, внутри сервиса они распространяются через описанный в докладе Mediator, который умеет пропускать через себя и команды, и события. В качестве приемника у нас выступает Handler, а не другой агрегат напрямую — это связано с тем, что временем жизни агрегата управляет ORM, и неудобно было бы регистрировать каждый новый instance в Mediator, хотя это технически реализуемо за счет interceptors NHibernate.
Как правильно организовывать варианты использования в application слое, наименование, группировка?
Не думаю, что могу сказать для всех кейсов, как делать правильно. Есть сервисы, где аппликационный слой содержит всю бизнес-логику, построен по шаблону Transaction Script, и это всех устраивает, так как в сервисе есть только CRUD. Бывает, что используется слой сервисов, и их группировка специфична в зависимости от количества разработчиков, источников изменений и подхода к декомпозиции предметной области. В своем докладе я приводил вариант реализации аппликационного слоя, который подхождит для сервисов со сложной бизнес-логикой, развитой доменной моделью и частыми изменениями этой самой логики. Это подход с атомарными функциями, где каждый use-case существует в виде отдельного класса Handler. Дальше можно пойти по пути отделения use-cases в сторону отдельных папок/модулей, которые будут соодержать один контроллер и один Handler на use-case. Тогда их можно будет добавлять и удалять независимо, конечно, с учетом того, что у них может быть общий код. Подробнее про этот подход можно узнать из доклада Быстрорастворимое проектирование Максима Аршинова. Наименование у нас по шаблону НазваниеUseCaseHandler, группировка связана с бизнес-процессом. Например, все Handler про жизненный цикл страховки группируются в папку Insurance, а отдельно идет папка InsuranceReports с отчетами по страховкам. Но каждый use-case в отдельном Handler.
Можете дать пару советов по поводу того, как побороть страх отсутствия транзакционной целостности между разными частями одной системы (ограниченными контекстами)?
У себя я поборол этот страх через практику. Я реализовывал итоговую согласованность на некритичных участках системы и проверял, будет ли работать. Всегда работало, и претензий не было. Кроме того, можно опереться на мнение сообщества, почитать статьи про итоговую согласованность. Еще я люблю мысленный эксперимент — даже самая страшная в мире операция с точки зрения транзакционности — снятие средств с одного счета и зачисление на другой — еще 50 лет назад обрабатывалась без всякой согласованности ручкой в гроссбухе, с задержкой в секунды. А те же самые повествования вполне могут быть ACID, если их грамотно приготовить. Так что итоговая согласованность очень много где применима, в моих системах нет проблем с финансовыми use-cases, поэтому они полностью строятся на ней, за исключением одного кейса, когда потребовались транзакционные повествования.
Ваш центр разработки обслуживает только российский филиал или глобальный? Если второе, то как организованно взаимодействие с зарубежными доменными экспертами?
Обслуживает только российский. С зарубежными коллегами взаимодействуют те, у кого есть интеграции с их системами. Взаимодействие, насколько мне известно, такое же, как мы сейчас работаем — по телефону, скайпу, зуму — это уже стало привычным.
Скажите пожалуйста, как вы храните данные из другого микросервиса (к примеру аккаунты) для пагинация, храните как неструктурированные данные или дублируются таблицы? Так как строить запрос на клиенте неэффективно.
Мне на практике не приходилось строить решения с пагинацией в последнее время, только на заре своей карьеры. Поэтому не могу поделиться практическим кейсом реализации.
Это очень сильно зависит от сервиса и времени его создания. 4 года назад мы допускали связывание агрегатов по ссылке, и не особо думали о концепции агрегатов вообще. Сейчас мы используем для связи агрегатов и идентификаторы (чаще для чтения), и события (для оповещения об изменениях). В новых системах в одном микросервисе живет только один агрегат, что автоматически приводит к отказу от прямых ссылок. По поводу событий, внутри сервиса они распространяются через описанный в докладе Mediator, который умеет пропускать через себя и команды, и события. В качестве приемника у нас выступает Handler, а не другой агрегат напрямую — это связано с тем, что временем жизни агрегата управляет ORM, и неудобно было бы регистрировать каждый новый instance в Mediator, хотя это технически реализуемо за счет interceptors NHibernate.
Как правильно организовывать варианты использования в application слое, наименование, группировка?
Не думаю, что могу сказать для всех кейсов, как делать правильно. Есть сервисы, где аппликационный слой содержит всю бизнес-логику, построен по шаблону Transaction Script, и это всех устраивает, так как в сервисе есть только CRUD. Бывает, что используется слой сервисов, и их группировка специфична в зависимости от количества разработчиков, источников изменений и подхода к декомпозиции предметной области. В своем докладе я приводил вариант реализации аппликационного слоя, который подхождит для сервисов со сложной бизнес-логикой, развитой доменной моделью и частыми изменениями этой самой логики. Это подход с атомарными функциями, где каждый use-case существует в виде отдельного класса Handler. Дальше можно пойти по пути отделения use-cases в сторону отдельных папок/модулей, которые будут соодержать один контроллер и один Handler на use-case. Тогда их можно будет добавлять и удалять независимо, конечно, с учетом того, что у них может быть общий код. Подробнее про этот подход можно узнать из доклада Быстрорастворимое проектирование Максима Аршинова. Наименование у нас по шаблону НазваниеUseCaseHandler, группировка связана с бизнес-процессом. Например, все Handler про жизненный цикл страховки группируются в папку Insurance, а отдельно идет папка InsuranceReports с отчетами по страховкам. Но каждый use-case в отдельном Handler.
Можете дать пару советов по поводу того, как побороть страх отсутствия транзакционной целостности между разными частями одной системы (ограниченными контекстами)?
У себя я поборол этот страх через практику. Я реализовывал итоговую согласованность на некритичных участках системы и проверял, будет ли работать. Всегда работало, и претензий не было. Кроме того, можно опереться на мнение сообщества, почитать статьи про итоговую согласованность. Еще я люблю мысленный эксперимент — даже самая страшная в мире операция с точки зрения транзакционности — снятие средств с одного счета и зачисление на другой — еще 50 лет назад обрабатывалась без всякой согласованности ручкой в гроссбухе, с задержкой в секунды. А те же самые повествования вполне могут быть ACID, если их грамотно приготовить. Так что итоговая согласованность очень много где применима, в моих системах нет проблем с финансовыми use-cases, поэтому они полностью строятся на ней, за исключением одного кейса, когда потребовались транзакционные повествования.
Ваш центр разработки обслуживает только российский филиал или глобальный? Если второе, то как организованно взаимодействие с зарубежными доменными экспертами?
Обслуживает только российский. С зарубежными коллегами взаимодействуют те, у кого есть интеграции с их системами. Взаимодействие, насколько мне известно, такое же, как мы сейчас работаем — по телефону, скайпу, зуму — это уже стало привычным.
Скажите пожалуйста, как вы храните данные из другого микросервиса (к примеру аккаунты) для пагинация, храните как неструктурированные данные или дублируются таблицы? Так как строить запрос на клиенте неэффективно.
Мне на практике не приходилось строить решения с пагинацией в последнее время, только на заре своей карьеры. Поэтому не могу поделиться практическим кейсом реализации.
Как приручить DDD
Константин Густов, Райффайзенбанк
О спикере: Разработкой ПО занимается уже больше 10 лет. На данный момент работает архитектором. Начинал с C++ и немного Delphi, потом полностью перешел на .NET и C#, чему очень рад. Сменил несколько предметных областей — от военной отрасли и энергетики нефтедобычи до банковского дела. Старается всегда придерживаться прагматичных подходов без крайностей. Работает с сервисными архитектурами и DDD.О докладе: На протяжении 5 лет мы в компании в различных проектах используем практики DDD. Они помогают нам декомпозировать системы на микросервисы, находить общий язык с заказчиком, создавать приложения, которые не сопротивляются новым требованиям, а также поддерживать качественное общение внутри команды. При этом часто от применения предметно-ориентированного проектирования отказываются из-за того, что это методология без четких указаний, что и как делать.
В докладе я расскажу о нашем применении этого подхода, какие хорошие практики мы используем, какие ошибки допускали и какие выводы из этого сделали.
ПРЕЗЕНТАЦИЯ
Старт разработки в новой предметной области с помощью DDD, на примере Rich Communication Services – замены обычных SMS-сервисов нативным IM-мессенджером мобильного оператора
Александр Лукашкин, FunBox
О спикере: Руководитель направления в FunBox. Прошёл путь от инженера до CTO. Запускал новые продукты, а иногда новых мобильных операторов с нуля. Сейчас занимается разработкой продуктов для нативного IM-мессенджера мобильного оператора.О докладе: Разработка для мобильных операторов – это пересечение разных предметных областей, “классических” и совсем новых. Что делать, если эти предметные области сложные и запутанные? Как быть, если для тебя, как для разработчика, эти предметные области – совершенно незнакомые? Разберёмся на примере Rich Communication Services.
RCS – это доступный абонентам из коробки нативный IM-мессенджер замена стандартного SMS-сервиса оператора с видео, интерактивом, геолокацией, групповыми чатами и другими возможностями. Причём это “всего лишь” один из сервисов, которые используют сеть IP Multimedia Subsystem оператора. В докладе я расскажу о практиках, которые мы используем для старта разработки в новых предметных областях. Подробно остановлюсь на том, как нам помогают принципы Domain-Driven Design.
Мы верим, что с помощью этих практик, команда может разобраться в чем угодно и нарастить необходимую экспертизу за короткий срок. Даже в разработке для мобильных операторов.
ПРЕЗЕНТАЦИЯ
