Guest
Довольно небольшой процент разработчиков точно знает, как и согласно каким принципам нужно проектировать мультисервисную архитектуру. Если на уровне приложения разработчики ещё худо-бедно разбираются, применяя общеизвестные принципы и шаблоны (SOLID, IoC и проч.), то при проектировании системы на уровень выше (межсервисное взаимодействие), как правило, всё намного сложнее. В большинстве случаев, всё сводится к перекрёстным связям между сервисами, что приводит к архитектурным проблемам, со всеми признаками плохой архитектуры (жёсткость, хрупкость, неподвижность, и так далее). Стоимость кода растёт, заказчик теряет деньги, разработчики мечутся от таски к таске, не успевая в спринт. Мы разобрали принципы предметно-ориентированного проектирования. Изучили признаки плохой архитектуры. Познакомились с требованиями к архитектуре хорошей. Выяснили, как спроектировать всю систему, начиная от отдельного сервиса до всей микросервисной архитектуры. И разобрали всё это на реальных примерах. Что по теме? План доклада: Описание проблемы: негативные примеры из личной практики. Знакомство. Признаки плохой архитектуры — разбираем подробно и с примерами. Требования к хорошей архитектуре — 6 основных. DDD: что такое, основные понятия (предметная область, ограниченный контекст и так далее). Микросервисная архитектура: как применить DDD на этом уровне (основные паттерны). Спускаемся ниже, на уровень отдельно взятого микросервиса. Как применить DDD на уровне сервиса. Старая добрая компоновка по слоям. Формируем предметные области, делим на контексты. Куда, в итоге, класть маперы. Подведение итогов.
