Комментарии 12
Домен (модель всего продукта) должен иметь свой ограниченный контекст?
Не совсем понял вопрос, но скорее нет, чем да. Понятие "должен" тут тоже не применимо
У домена нет ограниченного контекста - значит, что или домен не имеет контекста, или контекст не ограничен.
В 1-м случае домен перестаёт существовать, т.к. ничего не содержит. Отметаем.
Во 2-м случае мы можем напихать в контекст что угодно. В приведённом примере можно добавить, что компания занимается майнингом и торговлей криптовалюты для обеспечения закупок и взаиморасчётов. Теперь ваш домен включает приличный кусок деятельности, обеспечение которой может затмить (заменить, угробить) поставленную цель.
Так есть у домена свой ограниченный контекст или нет?
Пока не понимаю, почему ограниченный контекст внезапно появляется только в поддоменах
Допустим, что пишем автоматизацию бизнеса с очень узкой специализацией. Микросервисы ненужны, несколько команд для разработки не нужно - хватит одного разраба. Выходит, что у нас доменный контекст вмещает все, чем занимается бизнес. И ограничений нет пока мы не решим, что это не так. Не вижу тут противоречий. Когда специализация более широкая, то мы делим контекст бизнеса на части и получаем границы между ними и даем разным контекстам разные названия. До этого момента единственному контексту даже название не требовалось. На практике трудно представить домен с одним большим контекстом, так что это только умозрительная практика.
Из практики вижу, что лучшее сразу делить на микросервисы. Основные преимущества лично для меня: микросервисы получаются небольшими и их очень просто сопровождать и дорабатывать. Они изначально получаются автономными, т.е. работают в асинхронном режиме. Ну и огромный плюс - понятия бизнес области = микросервисам, что очень сильно облегчает понимание и проектирование бизнесовых процессов. Единственное, что приходится делать - аккуратно вести архитектуру. Использую для этого PlantUML и возможности его препроцессора.
А зачем вам домены? Вы как-то их используете? Почему с доменами такой принципиальный вопрос?
Ограниченный контекст это понятие скорее семантическое. Просто его вполне хорошо себе можно использовать для выполнения микросервисов
Удивительно, что под статьями посвященными стратегии в DDD практически нет комментариев. Сомневаюсь, что к этой тем нет интереса. Тогда что? Настолько мало специалистов, что прочитанное кажется дикими дебрями? Может потому что, люди видят рядом с упоминанием об ограниченных контекстах упоминание о микросервисах, прикидывают, что в микросервисную архитектуру лезть нет желания и закрывают статью? Но никто же не говорит, что ограниченные контексты не могут быть в монолите в виде отдельных хорошо изолированных модулей.
С моей точки зрения люди находятся в плену своего видения. Если один раз столкнулся с проблемой микросервисов, то начинаешь думать, что все микросервисы это лажа. Однако вероятно, что проблема с микроскопами возникла именно из-за их неправильного выделения и непонимания как их лучше использовать
Так можно не только про микросервисы сказать, но и про сам DDD. В темах посвященных тактике DDD комментариев сильно больше и, по моему, ни одна тема не обходится без
DDD - это полная лажа, так как куча абстракций и ненужных сложностей и невозможно отделить бизнеслогику от инфраструктуры
Меня, как разработчика на тактическом уровне, такие комментарии вымораживают куда больше.
Наверное я просто не встречался с ненужными сложностями. И логика вроде как изначально отделена от инфраструктуры. По крайней мере луковая архитектура вполне себе позволяет это сделать. Про кучу абстракций вообще интересно где нашли. Т.е. в целом складывается впечатление скорее о каком-то странном использовании ddd.
Буквально на днях общался с коллегой, который прошёл курсы Яндекса по ddd. Когда я рассказал ему своё понимание DDD и мы совместно расписали его примеры, он выпал в осадок насколько все по-другому.
Поэтому и говорю, что тут скорее похоже на недостаточное изучение темы
Собеседуя разрабов на вакансии в свою команду я ни разу не услышал от них, чтобы они использовали полноценно луковую архитектуру в предыдущих проектах. Всегда их решение каким-то причудливым образом оказывалось сильно завязанным на фреймворк. Конкретно говорю про appliaction слой, который, как мне кажется, самый простой в этом архитектурном паттерне - то его из контроллеров лепили, то каким-то образом систему управления событиями фреймворка приплетали, то еще что-то. Мне кажется, что сейчас в основном на рынке труда программисты, в сознании которых гвоздями прибито, что программируют на фреймворках. А архитектура - это то как папочки во фреймворке назвать.
Декомпозиция систем по ограниченным контекстам DDD — глубокое погружение