- #SkladchinaVip
- #1
[Thinknetica] Domain Driven Design в Ruby-приложениях. Тариф Слушатель [Игорь Симдянов]
- Ссылка на картинку
-
Этот воркшоп для вас, если:
DDD не дает простых ответов - это стратегия разработки, реализовать которую очень не просто:
Архитектурный подход Domain Driven Design (DDD) очень популярное направление, несмотря на то, что возник более 20 лет назад. На какую бы вы конференцию не попали, пару докладов будет посвящено этому подходу.
Интерес вызван тем, что DDD не дает простых ответов на то, как разрабатывать код. Это не тактический прием или набор принятых архитектурных решений. На самом деле это стратегия разработки хорошего программного обеспечения, реализовать которую очень не просто.
Много лет, практически с самого момента возникновения информационных технологий "бизнес" и "разработка" пробивали туннель через гору недопонимания. Со временем оказалось, что название этой горы "сложность".
В ходе этой работы родились объектно-ориентрованное программирование, UML, паттерны разработки, гибкие технологии. Однако, лучшим на текущий момент архитектурным подходом для борьбы со сложностью и наведению мостов между бизнесом и разработкой является Domain Driven Design.
Конечно, DDD — стратегия, ее не просто начать применять на практике, прочитав пару книг. Как заполнить стратегию практическими приемами и инструментами, мы разберемся на воркшопе.
Программа воркшопа:
День 1. Для чего нужен DDD
В этой части отвечаем на вопрос "Что?" и "Зачем?". Что такое архитектура, зачем она нужна. Как, опираясь на архитектуру можно накладывать на систему ограничения или наоборот выявлять их в предметной области и технологиях. Предъявляем системе нефункциональные требования.
Обсудим, зачем нужна архитектура и из каких слоев она состоит. Что такое Domain Driven Design и чем он ценен? Дадим определение ключевых терминов: домен, поддомен, контекст, единый язык.
Результат:
В этой части отвечаем на вопрос "Как?". Что делать с полученными на предыдущем дне воркшопа поддоменами? Это кандидаты для микросервисов. Фактически это отдельное рельсовое приложение, к которому могут обращаться пользователи или другие микросервисы.
В рамках решения бизнес-задачи два или более микросервисов могу составить целый протокол взаимодействия. К backend-микросервисам могут обращаться frontend-приложения. Причем разработка frontend-а и backend-а может вестись параллельно.
Встает задача создания контрактов между микросервисами как на уровне REST, так и на уровне асинхронного взаимодействия.
Результат:
Микросервис — небольшое приложение, покрывающее один поддомен бизнес-логики. Все было бы хорошо, если разработав приложение на основе микросервисов, мы бы его больше не трогали. Однако, если приложением пользуются, его потребуется дорабатывать и сопровождать.
Даже если не будут появляться новые фичи и бизнес-требования, вокруг приложения будет меняться технологический ландшафт. Так или иначе нам потребуется вносить изменения.
Так как микросервисов много — можно редактировать их независимо и довольно трудно поддерживать их единообразие, единые архитектурные решения. Потребуются отдельные усилия, чтобы поддерживать кодовую базу в едином архитектурном стиле.
Результат:
Solution Architect в Нетологии
- задачи "бизнеса" постоянно ломают ранее принятые архитектурные решения
- вы не понимаете, о чем говорит "заказчик" - все эти "сторнирования", "акты" вам непонятны
- вы оторваны от бизнес-контекста: коммуникация идёт через продактов и аналитиков.
- у вас в проекте архитектура есть, и даже неплохая, но она только в головах разработчиков и в соглашениях
DDD не дает простых ответов - это стратегия разработки, реализовать которую очень не просто:
Архитектурный подход Domain Driven Design (DDD) очень популярное направление, несмотря на то, что возник более 20 лет назад. На какую бы вы конференцию не попали, пару докладов будет посвящено этому подходу.
Интерес вызван тем, что DDD не дает простых ответов на то, как разрабатывать код. Это не тактический прием или набор принятых архитектурных решений. На самом деле это стратегия разработки хорошего программного обеспечения, реализовать которую очень не просто.
Много лет, практически с самого момента возникновения информационных технологий "бизнес" и "разработка" пробивали туннель через гору недопонимания. Со временем оказалось, что название этой горы "сложность".
В ходе этой работы родились объектно-ориентрованное программирование, UML, паттерны разработки, гибкие технологии. Однако, лучшим на текущий момент архитектурным подходом для борьбы со сложностью и наведению мостов между бизнесом и разработкой является Domain Driven Design.
Конечно, DDD — стратегия, ее не просто начать применять на практике, прочитав пару книг. Как заполнить стратегию практическими приемами и инструментами, мы разберемся на воркшопе.
Программа воркшопа:
День 1. Для чего нужен DDD
В этой части отвечаем на вопрос "Что?" и "Зачем?". Что такое архитектура, зачем она нужна. Как, опираясь на архитектуру можно накладывать на систему ограничения или наоборот выявлять их в предметной области и технологиях. Предъявляем системе нефункциональные требования.
Обсудим, зачем нужна архитектура и из каких слоев она состоит. Что такое Domain Driven Design и чем он ценен? Дадим определение ключевых терминов: домен, поддомен, контекст, единый язык.
Результат:
- Познакомимся с типами архитектур и современным архитектурным подходом Domain Driven Design (DDD).
- Научимся выявлять нефункциональные требования к системе и оформлять их в концепциях DDD.
- Освоим проведение штурма бизнес-задачи и установление единого языка.
- Изучим оформление результатов в виде Archimate-диаграмм в архитектурном редакторе archi.
- Архитектура и ее типы
- Domain Driven Design
- Домен и поддомен
- Контекст
- Единый язык
- EventStorming
- Архитектурный редактор archi
В этой части отвечаем на вопрос "Как?". Что делать с полученными на предыдущем дне воркшопа поддоменами? Это кандидаты для микросервисов. Фактически это отдельное рельсовое приложение, к которому могут обращаться пользователи или другие микросервисы.
В рамках решения бизнес-задачи два или более микросервисов могу составить целый протокол взаимодействия. К backend-микросервисам могут обращаться frontend-приложения. Причем разработка frontend-а и backend-а может вестись параллельно.
Встает задача создания контрактов между микросервисами как на уровне REST, так и на уровне асинхронного взаимодействия.
Результат:
- Освоим распределение поддоменов бизнес логики по микросервисам.
- Научимся использовать генераторы Rails-приложений для быстрого прототипирования.
- Изучим документирование контрактов при помощи OpenAPI и AsyncAPI.
- Разберем создание mock-серверов для тестирования и раздельной разработки backend и frontend-частей приложений.
- Микросервисная архитектура и ее связь с Domain Driven Design
- Генераторы Rails-приложений
- Информационная архитектура
- API: REST vs Асинхронное взаимодействие
- Контракты на API
- Документирование: OpenAPI и AsyncAPI
- Mock-сервера
Микросервис — небольшое приложение, покрывающее один поддомен бизнес-логики. Все было бы хорошо, если разработав приложение на основе микросервисов, мы бы его больше не трогали. Однако, если приложением пользуются, его потребуется дорабатывать и сопровождать.
Даже если не будут появляться новые фичи и бизнес-требования, вокруг приложения будет меняться технологический ландшафт. Так или иначе нам потребуется вносить изменения.
Так как микросервисов много — можно редактировать их независимо и довольно трудно поддерживать их единообразие, единые архитектурные решения. Потребуются отдельные усилия, чтобы поддерживать кодовую базу в едином архитектурном стиле.
Результат:
- Изучим как работать с требованиями, возникающими для уже созданной системы.
- Научимся сопровождать архитектурные решения.
- Освоим BPMN-диаграммы
- Аутентификация
- Архитектурные решения
- Сопровождение в archi
- BPMN-диаграммы
- Жизненный цикл программного обеспечения
Solution Architect в Нетологии
- разработчик с 25-летним стажем
- автор двух десятков книг по базам данных и веб-программированию, в том числе Самоучитель Ruby
- работал во множестве российских компаниях: заказной разработке, медиа, fintech и edtech.
- в настоящий момент работает архитектором решений в Нетологии.
Показать больше