Структура кода в папке Domain по DDD
В слое Domain 90% проектов с тактическим DDD забыли о самом главном. Сегодня мы вспомним то о чем забыли или узнаем то чего не знали.
https://habr.com/ru/articles/975936/
#DDD #domain_driven_design #domain_driven_development #backend #clean_architecture #bounded_context #domain #monolith
[Перевод] Связывая Контексты: Руководство по Эффективному Взаимодействию
В предыдущей статье “ Упакуйте свой код правильно ” мы рассмотрели различные подходы к организации кода, включая монолитную и многослойную архитектуры, принципы чистой архитектуры, а также концепцию Bounded Context (ограниченного контекста) в Domain-Driven Design ( DDD ). Мы узнали, что Bounded Context помогает структурировать сложные системы, разделяя их на логические части, каждая из которых имеет собственную модель предметной области с четкими и непротиворечивыми правилами. Теперь, когда мы понимаем, как выделять и организовывать bounded contexts, пришло время углубиться в следующий важный аспект DDD — коммуникацию между ними. В реальных системах bounded contexts редко существуют изолированно. Для реализации бизнес-процессов и обеспечения целостности системы необходимо организовать эффективное взаимодействие между ними. В этой статье мы рассмотрим, как bounded contexts могут общаться между собой, какие подходы к коммуникации существуют и как выбрать подходящий в зависимости от требований вашей системы. Продолжим наше путешествие в мир DDD , чтобы научиться создавать не только хорошо структурированные, но и слаженно работающие системы.
Тактические паттерны DDD
В предыдущей статье мы обсудили стратегические паттерны, а теперь давайте углубимся в тактические. Важно помнить: в DDD тактика без стратегии теряет смысл! Если вы не знаете, как правильно разделить систему, отдел или предприятие на контексты и поддомены, ваши усилия, направленные на тактические паттерны, вряд ли принесут плоды. Стратегическое мышление в сочетании с тактическими подходами поможет создать эффективную и гибкую архитектуру, способную справляться с изменениями и требованиями бизнеса.
https://habr.com/ru/articles/854140/
#ddd #domaindriven_design #domain_driven #bounded_context #subdomain #active_record #domain_model #event_storming #DDD_Trilemma #typescript
DDD простыми словами
Часто в больших компания всё поделено на большие системы. А если система «Legacy», т.е. устаревшая, то часто внутри неё собрано очень много разнородного функционала. По сути такие системы представляют из себя монолитных монстров. Бывает, что компании решают использовать микросервисный подход, но в результате получают таких же монолитных монстров, но только работающих в Кубере. Границы систем размыты, нет чёткого понимания, что должно входить в систему, а что нет. Команды сильно специализированы на конкретную систему и не могут участвовать в доработке никакой другой системы. По сути, речь идёт о том, что системы становится слишком большими и для их доработки требуется длительный процесс погружения. Можно ли исправить ситуацию коренным образом?
https://habr.com/ru/articles/809831/
#ddd #ограниченный_контекст #bounded_context #ubiquitous_language #domain_driven_design #архитектура #предметная_область
Стратегические паттерны DDD
В данной статье мы погрузимся в мир DDD, сфокусировавшись на самом важном аспекте – модульности. Разберем стратегические паттерны, предоставляющие необходимые инструменты для эффективной организации модульности на уровне организации. Обсудим, как определить границы между контекстами, установить правила взаимодействия и эффективно управлять сложностью в разработке крупных бизнес-приложений.
https://habr.com/ru/articles/787460/
#ddd #domaindriven_design #domain_driven #bounded_context #ubiquitous_language #subdomain #domain #patterns #ddd_дизайн #domain_driven_architecture
Habr
