Всем привет!
Когда сущности оживают: применение State в доменной модели DDD
Сущность в Domain Driven Design — это сердце бизнес-логики. Ее цель - моделирование бизнес-процессов и их жизненного цикла. Сущность инкапсулирует состояние и поведение важное для бизнеса.
Хореография + Domain-Driven Design: как они сочетаются
Представьте, что ваша система — это оркестр, где каждый музыкант знает свою партию, но никто не машет палочкой. Вместо хаоса — гармония бизнес-процессов. В этом посте разберем, как Domain-Driven Design (DDD) и хореография в распределенных системах создают именно такую синергию: от моделирования событий до масштабируемой архитектуры.
DDD Entity != ORM Entity: Почему это важно и как избежать "болевых точек" в архитектуре
Часто в проектах, которые разрабатываются с использованием подхода Domain Driven Design, возникает соблазн использовать одну и ту же Java сущность для двух принципиально разных целей. Один класс используется и как бизнес логика (DDD Entity), и как ORM сущность (часто это мотивируется следованию принципу DRY(Don't Repeat yourself), хотя он не имеет…
Как упростить работу с модульностью
Итак, мы решили стартовать наш проект с модульной архитектуры. Мы используем Spring Boot для разработки приложения на языке Java/Kotlin. Какие инструменты нам позволят упростить работу по реализации модульного монолита? Один из таких инструментов - Spring Modulith.
Модульный монолит, паттерны взаимодействия между модулями
Итак, мы решили начать проект с модульного монолита. Теперь встает вопрос каким образом построить коммуникацию между модулями. Одним из ключевых аспектов модульного монолита - организация правильного взаимодействия между модулями.
🧩 Как работать с данными в модульном монолите
В модульном монолите мы стремимся к максимальной независимости модулей, что также включает и работу с данными. Хотя все модули могут использовать общую БД, необходимо поддерживать строгую изоляцию данных для каждого модуля. Это предотвращает сильную связанность, упрощает рефакторинг и сохраняет возможность будущего выделения модулей в отдельные мик…
Организация модульного монолита
В прошлый раз рассмотрели что такое модульный монолит и откуда возникла сама идея. Сегодня начнем рассматривать как организовать модульный монолит.
🏛 Модульный монолит - старт для масштабируемой архитектуры
В прошлом посте мы обсудили, что старт разработки, особенно когда доменная область нам плохо известна, с микросервисной архитектуры не всегда является хорошей идеей. Сегодня разберем компромиссный вариант архитектуры — модульный монолит.
Почему микросервисы — плохой выбор для старта? Или как не утопить проект в техническом долгу.
Микросервисы стали настоящим символом современной разработки. Все хотят иметь гибкую, масштабируемую архитектуру, состоящую из маленьких независимых изолированных сервисов. Идея выглядит простой и привлекательной: небольшие независимые команды работают над отдельными сервисами, быстро выпускают обновления, легко поддерживают и развивают систему.
Когда DDD превращается в спагетти на стероидах: типичные ошибки в Aggregates и Entities
Domain-Driven Design (DDD) — мощный подход к проектированию сложных систем, который обещает порядок в сложных бизнес процессах, однако он также скрывает ряд ловушек, связанных с проектированием агрегатов (Aggregates), сущностей (Entities). Без должного внимания к процессу легко допустить ошибки, способные привести к спагетти коду на стероидах. Расс…
Как неправильное определение Bounded Context в DDD может сломать архитектуру: типичные ошибки и как их избежать
Впрошлый раз мы разобрали, как избежать ошибок при формировании Ubiquitous Language. Сегодня разберем какие ошибки могут возникнуть при определении Bounded Context.