Домен-ориентированный дизайн Точное совокупное определение

Агрегат - это все о предметной области: он представляет то, что является предметным для данной области знаний.

Напротив, репозиторий - это техническая вещь, которая заботится о постоянстве. Итак, репозиторий не принадлежит домену, это утилита для использования агрегатов.

Итак, нет, репозиторий не принадлежит агрегату. Вас также может заинтересовать этот вопрос для подробностей об этом.

Что касается вашего второго вопроса: это сильно зависит от вашего приложения и от языка программирования, который вы используете ... если вы используете язык с динамической типизацией, такой как JavaScript, вы все равно можете выполнять DDD, но вы не сможете создавать подклассы (оставив ES2015 class, поскольку оно не приносит настоящего объектно-ориентированного программирования в ES).

Кроме того, DDD - это способ моделировать домен и позволить междисциплинарным командам лучше общаться по этому поводу. Это не о технологиях (если, конечно, ваш домен на самом деле не технологии ;-)).

Поскольку создание подклассов - техническая проблема, она не связана с DDD. Если вообще, это связано с тем, как реализовать модель, созданную с использованием DDD, но это не зависит от самого DDD.

Возможно, вас заинтересует Совместное моделирование с вашей командой на основе документации wolkenkit, в которой описывается, как выполнять DDD и на что следует обращать внимание.

Обратите внимание, что я являюсь одним из авторов wolkenkit, фреймворка CQRS и поиска событий для Node.js и JavaScript. Поэтому, пожалуйста, отнеситесь к последнему абзацу с недоверием.

Является репозиторием частью агрегата

Нет, полностью отдельно

средство, с помощью которого сохраняется агрегат, принадлежащий уровню инфраструктуры?

И это тоже не совсем так.

Основная роль репозитория заключается в том, что он действует как граница между приложением и данными. Первоначальное обсуждение репозиториев в синей книге представило репозитории с семантикой коллекций; интерфейс для репозитория был таким же, как если бы данные просто хранились в коллекции в памяти.

Во-вторых, разумно ли увеличивать сложность и удобство обслуживания программного обеспечения для достижения читабельности, или это противоречит цели DDD в целом?

Не столько «читабельность», сколько «коммуникация»; см. главу 2 синей книги

В проекте без общего языка разработчики должны переводить для экспертов в предметной области .... Перевод запутывает концепции, что приводит к деструктивному рефакторингу кода .... Проект сталкивается с серьезными проблемами, когда его язык сломан ....

Сложность в данном случае - это сложность, извлеченная из предметной области - нам, вероятно, не следует воображать, что мы можем смоделировать предметную область с тысячей тонко различных концепций, используя одну или две абстракции, не зависящие от предметной области.

Вы заявляете, что считаете эту строку подкласса для простой читабельности, несмотря на то, что это может привести к сотням дополнительных классов, было бы разумным подходом, учитывая, что это послужило бы катализатором для общего языка

Конечно, не подклассы, нет. Но я бы рекомендовал иметь уникальное имя (в коде) для каждой уникальной концепции (в предметной области), даже если эти концепции имеют общие представления.

Чтобы выбрать наивный пример, Time не Money, даже в тех случаях, когда базовым представлением обоих является long.

«Моделирование предметной области, сделанное функциональным» Скотта Влашина включает расширенный пример. В какой-то момент он моделирует подтвержденный адрес электронной почты и непроверенный адрес электронной почты как явно отличающиеся друг от друга; даже несмотря на то, что у них обоих есть базовые строковые представления, он все же делает шаг по созданию единого типа объединения для каждого из них, чтобы зафиксировать в коде тот факт, что эти две концепции не заменяют друг друга.

Эта «сложность» на самом деле просто согласовывает артефакты кода с вездесущим языком экспертов предметной области.

Теперь, в зависимости от того, в какой Blub вы кодируете, может возникнуть дополнительная сложность в артефактах кода для создания эти разные имена; как демонстрирует Скотт, в F # это действительно просто, но может быть не так просто на вашем обычном рабочем языке. Я считаю, что если ваш выбор языка усложняет моделирование, то, возможно, вам сначала стоит посмотреть, есть ли другой язык, более подходящий для этой задачи.