DDD (Domain-Driving Design) — это концепция разработки ПО которая основывается на сущностях из предметной области разрабатываемого приложения. Эрик Эванс написал об этом книгу «Предметно-ориентированное проектирование» из которой мы узнали, что разработчику следует оперировать терминами из предметной области, следует понимать их, я бы добавил к этому что при материализации их в коде, стоит «затерминейтить» их — сделать отдельный неймспейс сущности которого не будут ссылаться ни на что. Но, они могут ссылаться (зависеть) друг на друга и, более того, bounded context как раз об этом. Сами модели доменов действуют как UbiquitousLanguage (вездесущий язык) для коммуникации между специалистами в предметной области и разработчиками.

Домены — базовые сущности, значение которых должно быть однозначным, это очень важно при создании ПО. В реальных организациях, кстати, это часто не так и многие термины внутри одной большой организации могут пониматься по-разному в разных отделах. В мире компьютеров это недопустимо. Можно построить тотальную схему моделей всего бизнеса с уникальными сущностями? Ответ: это очень сложно и дорого. Ведь если под термином X в одном отделе понимается нечто, а в другом отделе понимается что-то похожее, но с существенными различиями, то сложно будет зафиксировать единое определение доменной сущности удовлетворяющее всех. Проще оставить разделение по отделам внутри каждого из которых будет своя модель доменов, да и продумать все модели с учетом будущего развития — задача сложная и бизнес не готов отдать столько времени на проектирование.

Итак, связанный контекст позволяет на высоком уровне смапить взаимоотношения сущностей между крупными логическими блоками приложения, в которых домены с одинаковыми названиями будут иметь свои, локальные, особенности и черты. Это позволяет нам не собирать единую гигантскую систему доменов, а оставить слабовязанные «микросервисы» жить отдельно.