Не, ну выгода есть не только для менеджмента. Узкоспециализированные микросервисы снижают когнитивную нагрузку на программиста. Программист понимает, что пусть хоть весь остальной мир рухнет - все равно. Он всего лишь занимается конкретной функциональностью, которая реализует заданные контракты - API и результат вызова этого API. Никаких "А если", "А вдруг".
Не практическая выгода, а возможная выгода. Возможность нужно уметь реализовать. Реализована ли возможность получения этой выгоды в проектах, где есть микросервисы? Все ли в организации получили выгоду или кто-то один, имеющий самый громкий голос? Ответ не всегда очевиден.
Зачем замахиваться на Марс? Однажды человек уже изжил неандертальцев в межвидовой борьбе. Ну так получилось. А вообще, обсуждать эмпатию и сопричастность к совершенно иной расе вот так между делом без уточнения просто вагонов различных аспектов, будет совершенно беспредметно. Но одно могу сказать точно - пока чужаки не несут вред моей расе - я не вижу причины делать развлечения из их убийства. Ничто гуманное мне не чуждо. Если говорить про игры, где марсиане выступают в виде зомби в зомби шутере, то да - я буду смотреть на это спокойнее, хоть и буду испытывать сожаление, что утеряна возможность сотрудничества с внеземной расой. Вообще мое мировоззрение вполне укладывается в концепцию родственного отбора (kin selection). Иной вид не имеет со мной общих генов, но у него могут быть общие со мной (если мы представляем гипотетическое планетарное общежитие нескольких рас) заслуги в становлении Солнечной системы, поэтому ничего приятного от их уничтожения быть не должно. Мне кажется, что вы хотели другого ответа, но уже как получилось.
нормальный японец мне ближе, чем отечественный гопник и бандит
Почему вы сравниваете нормальное с ненормальным? Почему выпали из сравнения японские гопники и бандиты? И почему вы так акцентируетесь именно на своих-чужих. Я уже в третьем комментарии говорю, что крошить в игре соотечественников - лишь усугубляет неприятие, но при этом я воспринимаю всю Землю как большую родину и крошить тех же японцев мне не доставит удовольствие. Вам так хочется поговорить про национальную идентичность и кто лучше кого? Мне - нет.
Странно услышать именно про евреев в этом контексте. Особенно в контексте цитаты Нагорной проповеди Иисуса Христа из Библии. Хотите сказать, что творение евреев обернулось против них самих?
Ну и не одних только евреев делали крайними в истории. Китайцы индийцев винят. Индийцы - пакистанцев. Японцы - китайцев. Китайцы, например, вашего посыла про евреев вообще не поймут. Они про такой народ узнали не так давно по историческим меркам.
Я про национальность не говорил. Я говорил про соотечественников - разница очень большая. Так же я упомянул Землю как большую родину. Ну и про мародёров... Сюжет должен быть прям чертовски убедителен, чтобы видеть в убиваемых людях именно мародёров, а не просто случайных людей, соотечественников, лишь сценарным произволом противопоставленных игроку. А можно еще одну грань темы рассмотреть: представьте зомби апокалипсис. Допустим создатель игры был настолько талантлив, что смог достоверно передать ваш родной город и колорит людей, живущих в них. Настолько достоверно, что вы неосознанно понимаете, что убиваете бывших своих одноклассников, учителей, соседей, сёстр и братьев своих друзей. Каково воспринимать такой сеттинг с геймплеем увлекательного истребления зараженных? Одно дело обезличенный враг или враг человечества. Другое дело - развлечение из изничтожения своего же населения. Я не страдаю морализаторством. Я сам краешком задел игропром в своей профессиональной деятельности и не перестал мечтать стать автором какой-то AAA игры. Но в мечтах постоянно натыкаюсь на мысль, что реализуя понравившиеся еще в 90-е игры в сеттинге Средней Азии я неминуемо столкнусь с тем, что устрою кровавое развлечение из изничтожения тех, к кому сам чувствую какую-то сопричастность. Мой посыл эмоциональный и на срыв покров с истин не претендует. Скорее я ждал сопереживания.
Посмотрел трейлер и вновь испытал то чувство, из-за которого никогда не стал бы подобные игры делать в сеттинге своей страны, если имел бы такие возможности. Были несбыточные мечты переделать Fallout или подобные игры. Для меня непонятна идея делать развлечение из убийства соотечественников. Кто-то спросит, мол убивать людей из других стран приятнее? Нет, Земля - большая родина, так что приятного тут ничего нет. Но соотечественников рубить ради веселья - это вообще бредово.
Целью инкапсуляции является обеспечение согласованности внутреннего состояния объекта.
Более техническое определение: инкапсуляция - процесс соблюдения инвариантов. Что по сути одно и тоже, но более привычно уху программиста. Есть и куча других мест, где достаточно авторитетно это заявляется. Сокрытие внутренней сложности - это побочный, но приятный бонус, дающий возможность не замусоривать публичный API объекта и экономить когнитивный ресурс программиста. Давайте договоримся, что вы усвоите эту информацию прежде чем спорить о чем-то еще.
Под инкапсуляцией вы видимо имеете в виду сокрытие деталей реализации от внешнего кода?
Инкапсуляция - это процесс соблюдения инвариантов объекта самим объектом. Если инварианты объекта инкапсулированы в объекте, то объект не позволяет себя создать в невалидном состоянии и не позволяет путем вызова какого либо его метода привести его в невалидное состояние. Ни слова про сокрытие. И я не пойму почему вообще речь пошла про свойства?
В Rich Model гораздо больше недостатков, просто вы их не замечаете по вышеуказанной причине. От смешивания разных уровней абстракции до сложностей с пробросом зависимостей внутрь и ошибок валидации наружу для показа в интерфейсе.
Про смешивания уровней абстракции - не смешивайте и не будет таких недостатков. Доменный слой работает только с инструментами доменного слоя. Под капотом реализация этих инструментов может быть в слое инфраструктуры, но это implementation details.
Сложность с пробросом зависимостей в некоторых проектах действительно есть, но в своих проектах я эту сложность преодолел выиграв при этом в производительности.
Ошибки домена не связаны с интерфейсом. Наверх вы можете пробросить исключение, произошедшее в домене. Такое исключение должно отловиться в application слое, который уже решит какое исключение application слоя бросить дальше. Но скорее вы говорите про валидацию форм - тут вообще все еще на уровне контроллера с валидаторами в большинстве случаев должно решиться. Для более специфичных случаев должны быть и более специфичные решения, которые будут специфичными как с анемичными моделями, так и с rich моделями.
При этом практически все недостатки Anemic Model там тоже есть, просто в другом виде. Например, возможность приведения сущности в некорректное состояние. Я могу добавить в сущность новый метод и привести ее там в любое состояние, так же как с логикой в сервисах.
Если вы позволяете создаться сущности в невалидном состоянии, то о какой инкапсуляции и Rich моделях может идти речь?
Представьте, что все значения свойств сущности хранятся в одном поле data в виде JSON. Это детали реализации. Как будет выглядеть ваша бизнес-логика внутри сущности с обращениями к такому полю?
какая разница как хранится информация в БД или в файлах? Если мне нужно восстанавливать состояние доменной модели из JSON, то на уровне инфраструктуры я это сделаю, но доменный слой об этом знать не будет. Из БД я, ведь, тоже не сразу объекты получаю, а всего лишь ответ об БД, который еще сопоставить с доменной моделью нужно.
Да, вы правы - тавтология. С другой стороны ChatGPT говорит, что это и не тавтология и не оксюморон, а уточнение контекста действия с усилением его отрицательной окраски. Тут явно нужна комиссия когнитивных лингвистов.
Вот тут не согласен. Функции с таким богатым набором комбинаций входных параметров - зло. Лучше иметь разные функции со строгим набором параметров. Тот жеstr_replace в зависимости от того - массив передан или скаляр в первые два параметра - сильно меняет свое поведение. Зачем нужна эта магия?
Если вы под бизнес-логикой понимаете что-то другое, то у вас и будет не DDD, а какой-то свой подход.
Бизнеслогика - это автоматизированная логика бизнеса инкапсулированная в модель бизнеса. Автоматизация может содержать свою специфику такую, как логирование, транзакции, исключения и прочее и прочее - все это бизнеслогика. У вас, если отбросить словесную шелуху, есть только два подхода:
излагать бизнеслогику в use case-ах, тем самым нарушая инкапсуляцию доменной модели
соблюсти инкапсуляцию доменной модели и оставить use case-ы условно однострочными (должен быть только один вызов метода доменной модели, обработка исключений и форматирование выходных данных для возврата клиентскому коду) - это и есть Rich Model.
Можете для интереса еще почитать про DDD трилемму.
Допустим, у какой-то сущности есть статус "На модерации". В это время пользователь не может ее редактировать. При попытке изменить любые данные API должно возвращать ошибку "Сущность находится на модерации" (допустим у нас сложный агрегат, и есть разные методы редактирования). Но прохождение модерации означает изменение статуса, а это тоже редактирование, но его делать можно. При этом самому пользователю не должно быть разрешено менять этот статус. Тут нужные проверки зависят от действия.
Извините, но это какая-то софистика. Если сущность на модерации, то это не означает, что она не может быть изменена. Это означает лишь то, что она на модерации. Доменная модель может бросать исключение, если вы вызываете ее методы, которые должны изменить ее состояние от имени клиента, если статус модели "на модерации". Это обычная State Machine. Но в то же время модель может получать изменения от операторов back office-а.
Логика в сервисах это вполне нормальное решение. Оно универсально, его можно использовать даже если у вас не сущности с базой данных, а стороннее API с названиями процедур, которое хранит данные на своей стороне. Все недостатки, которые можно найти у логики в сервисах, есть и у логики в сущностях, просто немного в другом виде. Только не все это замечают. У меня есть статья на эту тему с примерами кода, посмотрите если интересно.
Почитайте про нарушение инкапсуляции, чтобы понять, что это не так. Логика вынесенная из объектов в сервисы - это вынос инвариантов объекта вовне. Вследствие чего объект не может отвечать за свое состояние. Вместо него за инварианты отвечает облако сервисов вокруг него. А учитывая, что один и тот же метод объекта неизбежно будет вызываться в разных сервисах, мы получаем дублирование кода при попытке соблюсти инварианты. А потом получаем и проблему с поддержкой. Это когда логика соблюдения инвариантов размазана по всему проекту и программист будет бояться изменить что-то в одном месте, так как не будет знать во скольких местах это еще исправить, чтобы проект не посыпался. Про unit тестирование я вообще не говорю - тестирование сервисов application слоя - самая бесполезная вещь. Что полезнее тестировать: модель или кучу подпорок в виде сервисов, которые не дают ей упасть?
Абсолютно точно, анемичная модель - это вполне нормальное решение.
Мне кажется, что вы рано сдались в споре. Можно было еще упомянуть, что анемичные модели достаточно давно уже считаются антипаттерном и нет пока ни одного подхода, который бы нивелировал негативные последствия несоблюдения инкапсуляции доменных моделей. Rich Model в свою очередь имеет только один недостаток - часто Aggregate Root обрастает слишком уж большим количеством методов. С такой проблемой я и мои сотрудники жить готовы, так как альтернатива страшнее.
Событие предметной области — это то, что произошло в предметной области и о чем вы хотите уведомить остальные части той же предметной области (внутрипроцессно). Обычно уведомленные части каким-то образом реагируют на события.
Видимо, действительно, доменные события - это внутрипроцессные события. То есть события конкретного ограниченного контекста. В микросервисной архитектуре такими событиями будут внутренние события микросервиса, на которые реагирует только он сам.
Интеграционные события из-за того, что они так же порождаются в следствии изменения доменной части, тоже доменные. Но служат для оповещения прочих микросервисов. Это мое мнение.
Мне кажется, что в классификацию событий изначально была заложена неоднозначность. Если создавать проект по DDD, то все события не касающиеся инфраструктуры (события фреймворка и библиотек), априори доменные.
Но так же согласен с @KrawMire, что есть вопрос - что считать процессом. Например, в монолите при хорошей модульности (изоляции модулей) можно считать интеграционными событиями те события, на которые могут подписаться модули, не бросавшие это событие.
А зачем делать разницу между доменными и интеграционными событиями? В DDD проекте все события доменные, просто часть из них выполняют к тому же и роль интеграционных событий. Можно сделать реализацию, при которой они будут отличаться только конфигурацией. Конечно, есть ещё мнение, что интеграционные доменные события должны содержать больше сопроводительной информации, но это уже предмет холивара.
Собеседуя разрабов на вакансии в свою команду я ни разу не услышал от них, чтобы они использовали полноценно луковую архитектуру в предыдущих проектах. Всегда их решение каким-то причудливым образом оказывалось сильно завязанным на фреймворк. Конкретно говорю про appliaction слой, который, как мне кажется, самый простой в этом архитектурном паттерне - то его из контроллеров лепили, то каким-то образом систему управления событиями фреймворка приплетали, то еще что-то. Мне кажется, что сейчас в основном на рынке труда программисты, в сознании которых гвоздями прибито, что программируют на фреймворках. А архитектура - это то как папочки во фреймворке назвать.
Допустим, что пишем автоматизацию бизнеса с очень узкой специализацией. Микросервисы ненужны, несколько команд для разработки не нужно - хватит одного разраба. Выходит, что у нас доменный контекст вмещает все, чем занимается бизнес. И ограничений нет пока мы не решим, что это не так. Не вижу тут противоречий. Когда специализация более широкая, то мы делим контекст бизнеса на части и получаем границы между ними и даем разным контекстам разные названия. До этого момента единственному контексту даже название не требовалось. На практике трудно представить домен с одним большим контекстом, так что это только умозрительная практика.
Не, ну выгода есть не только для менеджмента. Узкоспециализированные микросервисы снижают когнитивную нагрузку на программиста. Программист понимает, что пусть хоть весь остальной мир рухнет - все равно. Он всего лишь занимается конкретной функциональностью, которая реализует заданные контракты - API и результат вызова этого API. Никаких "А если", "А вдруг".
Не практическая выгода, а возможная выгода. Возможность нужно уметь реализовать. Реализована ли возможность получения этой выгоды в проектах, где есть микросервисы? Все ли в организации получили выгоду или кто-то один, имеющий самый громкий голос? Ответ не всегда очевиден.
То, что вы описываете, называется: изжили и ассимилировали скромные остатки.
Зачем замахиваться на Марс? Однажды человек уже изжил неандертальцев в межвидовой борьбе. Ну так получилось. А вообще, обсуждать эмпатию и сопричастность к совершенно иной расе вот так между делом без уточнения просто вагонов различных аспектов, будет совершенно беспредметно. Но одно могу сказать точно - пока чужаки не несут вред моей расе - я не вижу причины делать развлечения из их убийства. Ничто гуманное мне не чуждо. Если говорить про игры, где марсиане выступают в виде зомби в зомби шутере, то да - я буду смотреть на это спокойнее, хоть и буду испытывать сожаление, что утеряна возможность сотрудничества с внеземной расой.
Вообще мое мировоззрение вполне укладывается в концепцию родственного отбора (kin selection). Иной вид не имеет со мной общих генов, но у него могут быть общие со мной (если мы представляем гипотетическое планетарное общежитие нескольких рас) заслуги в становлении Солнечной системы, поэтому ничего приятного от их уничтожения быть не должно.
Мне кажется, что вы хотели другого ответа, но уже как получилось.
Почему вы сравниваете нормальное с ненормальным? Почему выпали из сравнения японские гопники и бандиты? И почему вы так акцентируетесь именно на своих-чужих. Я уже в третьем комментарии говорю, что крошить в игре соотечественников - лишь усугубляет неприятие, но при этом я воспринимаю всю Землю как большую родину и крошить тех же японцев мне не доставит удовольствие. Вам так хочется поговорить про национальную идентичность и кто лучше кого? Мне - нет.
Странно услышать именно про евреев в этом контексте. Особенно в контексте цитаты Нагорной проповеди Иисуса Христа из Библии. Хотите сказать, что творение евреев обернулось против них самих?
Ну и не одних только евреев делали крайними в истории. Китайцы индийцев винят. Индийцы - пакистанцев. Японцы - китайцев. Китайцы, например, вашего посыла про евреев вообще не поймут. Они про такой народ узнали не так давно по историческим меркам.
Я про национальность не говорил. Я говорил про соотечественников - разница очень большая. Так же я упомянул Землю как большую родину. Ну и про мародёров... Сюжет должен быть прям чертовски убедителен, чтобы видеть в убиваемых людях именно мародёров, а не просто случайных людей, соотечественников, лишь сценарным произволом противопоставленных игроку.
А можно еще одну грань темы рассмотреть: представьте зомби апокалипсис. Допустим создатель игры был настолько талантлив, что смог достоверно передать ваш родной город и колорит людей, живущих в них. Настолько достоверно, что вы неосознанно понимаете, что убиваете бывших своих одноклассников, учителей, соседей, сёстр и братьев своих друзей. Каково воспринимать такой сеттинг с геймплеем увлекательного истребления зараженных?
Одно дело обезличенный враг или враг человечества. Другое дело - развлечение из изничтожения своего же населения.
Я не страдаю морализаторством. Я сам краешком задел игропром в своей профессиональной деятельности и не перестал мечтать стать автором какой-то AAA игры. Но в мечтах постоянно натыкаюсь на мысль, что реализуя понравившиеся еще в 90-е игры в сеттинге Средней Азии я неминуемо столкнусь с тем, что устрою кровавое развлечение из изничтожения тех, к кому сам чувствую какую-то сопричастность.
Мой посыл эмоциональный и на срыв покров с истин не претендует. Скорее я ждал сопереживания.
Посмотрел трейлер и вновь испытал то чувство, из-за которого никогда не стал бы подобные игры делать в сеттинге своей страны, если имел бы такие возможности. Были несбыточные мечты переделать Fallout или подобные игры. Для меня непонятна идея делать развлечение из убийства соотечественников. Кто-то спросит, мол убивать людей из других стран приятнее? Нет, Земля - большая родина, так что приятного тут ничего нет. Но соотечественников рубить ради веселья - это вообще бредово.
То-то я после двух кружек пива чувствую себя неустойчиво и ищу третью опору
Это да, но озвучка там просто шикарная. Я бы послушал эти тексты просто отдельно от игры
Сколько лет уже светлые умы пытаются отучить людей от того, что инкапсуляция про сокрытие, а никак не получается. Даже на Wiki написано (https://ru.wikipedia.org/wiki/Инкапсуляция_(программирование))
Более техническое определение: инкапсуляция - процесс соблюдения инвариантов. Что по сути одно и тоже, но более привычно уху программиста.
Есть и куча других мест, где достаточно авторитетно это заявляется. Сокрытие внутренней сложности - это побочный, но приятный бонус, дающий возможность не замусоривать публичный API объекта и экономить когнитивный ресурс программиста. Давайте договоримся, что вы усвоите эту информацию прежде чем спорить о чем-то еще.
Инкапсуляция - это процесс соблюдения инвариантов объекта самим объектом. Если инварианты объекта инкапсулированы в объекте, то объект не позволяет себя создать в невалидном состоянии и не позволяет путем вызова какого либо его метода привести его в невалидное состояние. Ни слова про сокрытие. И я не пойму почему вообще речь пошла про свойства?
Про смешивания уровней абстракции - не смешивайте и не будет таких недостатков. Доменный слой работает только с инструментами доменного слоя. Под капотом реализация этих инструментов может быть в слое инфраструктуры, но это implementation details.
Сложность с пробросом зависимостей в некоторых проектах действительно есть, но в своих проектах я эту сложность преодолел выиграв при этом в производительности.
Ошибки домена не связаны с интерфейсом. Наверх вы можете пробросить исключение, произошедшее в домене. Такое исключение должно отловиться в application слое, который уже решит какое исключение application слоя бросить дальше. Но скорее вы говорите про валидацию форм - тут вообще все еще на уровне контроллера с валидаторами в большинстве случаев должно решиться. Для более специфичных случаев должны быть и более специфичные решения, которые будут специфичными как с анемичными моделями, так и с rich моделями.
Если вы позволяете создаться сущности в невалидном состоянии, то о какой инкапсуляции и Rich моделях может идти речь?
какая разница как хранится информация в БД или в файлах? Если мне нужно восстанавливать состояние доменной модели из JSON, то на уровне инфраструктуры я это сделаю, но доменный слой об этом знать не будет. Из БД я, ведь, тоже не сразу объекты получаю, а всего лишь ответ об БД, который еще сопоставить с доменной моделью нужно.
Да, вы правы - тавтология. С другой стороны ChatGPT говорит, что это и не тавтология и не оксюморон, а уточнение контекста действия с усилением его отрицательной окраски. Тут явно нужна комиссия когнитивных лингвистов.
Вот тут не согласен. Функции с таким богатым набором комбинаций входных параметров - зло. Лучше иметь разные функции со строгим набором параметров. Тот же
str_replaceв зависимости от того - массив передан или скаляр в первые два параметра - сильно меняет свое поведение. Зачем нужна эта магия?Бизнеслогика - это автоматизированная логика бизнеса инкапсулированная в модель бизнеса. Автоматизация может содержать свою специфику такую, как логирование, транзакции, исключения и прочее и прочее - все это бизнеслогика. У вас, если отбросить словесную шелуху, есть только два подхода:
излагать бизнеслогику в use case-ах, тем самым нарушая инкапсуляцию доменной модели
соблюсти инкапсуляцию доменной модели и оставить use case-ы условно однострочными (должен быть только один вызов метода доменной модели, обработка исключений и форматирование выходных данных для возврата клиентскому коду) - это и есть Rich Model.
Можете для интереса еще почитать про DDD трилемму.
Извините, но это какая-то софистика. Если сущность на модерации, то это не означает, что она не может быть изменена. Это означает лишь то, что она на модерации. Доменная модель может бросать исключение, если вы вызываете ее методы, которые должны изменить ее состояние от имени клиента, если статус модели "на модерации". Это обычная State Machine. Но в то же время модель может получать изменения от операторов back office-а.
Почитайте про нарушение инкапсуляции, чтобы понять, что это не так. Логика вынесенная из объектов в сервисы - это вынос инвариантов объекта вовне. Вследствие чего объект не может отвечать за свое состояние. Вместо него за инварианты отвечает облако сервисов вокруг него. А учитывая, что один и тот же метод объекта неизбежно будет вызываться в разных сервисах, мы получаем дублирование кода при попытке соблюсти инварианты. А потом получаем и проблему с поддержкой. Это когда логика соблюдения инвариантов размазана по всему проекту и программист будет бояться изменить что-то в одном месте, так как не будет знать во скольких местах это еще исправить, чтобы проект не посыпался. Про unit тестирование я вообще не говорю - тестирование сервисов application слоя - самая бесполезная вещь. Что полезнее тестировать: модель или кучу подпорок в виде сервисов, которые не дают ей упасть?
Мне кажется, что вы рано сдались в споре. Можно было еще упомянуть, что анемичные модели достаточно давно уже считаются антипаттерном и нет пока ни одного подхода, который бы нивелировал негативные последствия несоблюдения инкапсуляции доменных моделей. Rich Model в свою очередь имеет только один недостаток - часто Aggregate Root обрастает слишком уж большим количеством методов. С такой проблемой я и мои сотрудники жить готовы, так как альтернатива страшнее.
https://learn.microsoft.com/ru-ru/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/domain-events-design-implementation:
Видимо, действительно, доменные события - это внутрипроцессные события. То есть события конкретного ограниченного контекста. В микросервисной архитектуре такими событиями будут внутренние события микросервиса, на которые реагирует только он сам.
Интеграционные события из-за того, что они так же порождаются в следствии изменения доменной части, тоже доменные. Но служат для оповещения прочих микросервисов. Это мое мнение.
Мне кажется, что в классификацию событий изначально была заложена неоднозначность. Если создавать проект по DDD, то все события не касающиеся инфраструктуры (события фреймворка и библиотек), априори доменные.
Но так же согласен с @KrawMire, что есть вопрос - что считать процессом. Например, в монолите при хорошей модульности (изоляции модулей) можно считать интеграционными событиями те события, на которые могут подписаться модули, не бросавшие это событие.
А зачем делать разницу между доменными и интеграционными событиями? В DDD проекте все события доменные, просто часть из них выполняют к тому же и роль интеграционных событий. Можно сделать реализацию, при которой они будут отличаться только конфигурацией. Конечно, есть ещё мнение, что интеграционные доменные события должны содержать больше сопроводительной информации, но это уже предмет холивара.
Собеседуя разрабов на вакансии в свою команду я ни разу не услышал от них, чтобы они использовали полноценно луковую архитектуру в предыдущих проектах. Всегда их решение каким-то причудливым образом оказывалось сильно завязанным на фреймворк. Конкретно говорю про appliaction слой, который, как мне кажется, самый простой в этом архитектурном паттерне - то его из контроллеров лепили, то каким-то образом систему управления событиями фреймворка приплетали, то еще что-то. Мне кажется, что сейчас в основном на рынке труда программисты, в сознании которых гвоздями прибито, что программируют на фреймворках. А архитектура - это то как папочки во фреймворке назвать.
Допустим, что пишем автоматизацию бизнеса с очень узкой специализацией. Микросервисы ненужны, несколько команд для разработки не нужно - хватит одного разраба. Выходит, что у нас доменный контекст вмещает все, чем занимается бизнес. И ограничений нет пока мы не решим, что это не так. Не вижу тут противоречий. Когда специализация более широкая, то мы делим контекст бизнеса на части и получаем границы между ними и даем разным контекстам разные названия. До этого момента единственному контексту даже название не требовалось. На практике трудно представить домен с одним большим контекстом, так что это только умозрительная практика.