репозитории и запросы с помощью необработанного sql?

У меня есть репозитории с множеством методов, которые возвращают комбинацию как сущностей, так и скалярных значений. Кажется, это приводит к «взрыву метода». Должен ли я всегда возвращать объект Entity? Как мне запрашивать объекты, где мне нужен только один столбец?

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

Должен ли я при выполнении запроса включать каждый столбец в таблицу, даже если мне нужен только один или два столбца? Если я создам для этого специальные запросы, это приведет к увеличению количества методов в репозитории.

Это не вопрос DDD. Доменный дизайн не имеет отношения к "строкам и столбцам". Всегда есть некоторая избыточность в том, сколько данных вы загружаете для «гидратации» объекта предметной области, но вы должны измерить, действительно ли это влияет на вашу производительность. Если это действительно узкое место в производительности, то это может быть признаком неправильной модели предметной области.

Как я должен предоставить условия для запроса? Я читал о спецификациях, но, насколько я понимаю, вы перебираете возвращенные записи и отфильтровываете те, которые переходят в новую коллекцию. Это не похоже на хорошую идею с точки зрения производительности. Прямо сейчас я просто создаю новый метод в репо, например getNameById(), который инкапсулирует условие.

Это снова проблема доступа к данным. Ничто в DDD не говорит о том, что ваш репозиторий не может преобразовать спецификацию в SQL-запрос. Это зависит от вас, делаете ли вы это или перебираете записи в памяти (пока потребитель репозитория видит только спецификацию и репозиторий и не знает о фактической реализации).

Что касается «Необработанного SQL против ORM в DDD», вы можете найти этот ответ интересным.

Я согласен со всем, что говорит Дмитрий, но, возможно, вам следует прочитать CQRS.

Когда я начинал работу с DDD, я задавал подобные вопросы (о «взрыве метода», а не о проблемах с SQL), и это привело меня к CQRS. Лично я не очень понимаю, насколько DDD практична без него, и он отвечает на множество подобных вопросов, когда дело доходит до запроса данных. Используя его принципы, я бы предложил:

1. Используйте репозитории домена только при совершении транзакции. То есть вы не используете репозитории для отображения данных в пользовательском интерфейсе. Вы извлекаете агрегаты из своего репозитория только тогда, когда хотите выполнить над ними операцию.
2. Ваши репозитории возвращают только агрегаты, а не отдельные объекты по отдельности. Теперь это имеет смысл, так как мы используем репозитории только в транзакционном смысле, а сущности могут быть изменены только с помощью атомарных операций и сохранены агрегатом в целом.
3. Вы создаете отдельные репозитории (или «службы запросов»), которые предоставляют индивидуальные запросы и типы данных для любых данных, которые вам нужны. Они могут возвращать глупые DTO без какой-либо логики.

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

Что касается шаблона спецификации: вместо того, чтобы преобразовывать его в SQL-запрос в коде, вы можете предоставить общедоступные свойства в спецификации, которые представляют критерии. Затем эти значения могут быть добавлены в предложение where вашего SQL или отправлены в качестве параметров в SPROC.

Прежде всего, вы толком не объяснили, для чего вы используете все эти запросы. Скорее всего, это для нужд пользовательского интерфейса. Если это так, нет необходимости прыгать через все эти обручи (сервис-> репозиторий-> домен-> dto-> клиент), просто запросите базу данных как можно напрямую. И что вы знаете, исчезли вопросы о том, можете ли вы запрашивать скаляры или только нужные вам столбцы. Просто используйте простой sql и верните то, что вам нужно. Не создавайте абстракции, которые вызывают трения.

Чобо,

Нам нужно помнить две вещи о шаблоне Repository [Fowler PoEAA][Evans DDD]:

1. Используйте шаблон репозитория как простую коллекцию. Репозиторий абстрагирует эти детали инфраструктуры, потому что они не из домена.
2. Если шаблон репозитория является коллекцией, это кластер объектов одного типа.

Два других типа могут помочь вашему репозиторию: шаблоны Query Object [Fowler PoEAA] и Data Mapper [Fowler PoEAA]. Критерии агрегирования шаблона Query Object с использованием объектно-ориентированных методов и знание того, как преобразовать их в оператор SQL. Паттерн Data Mapper умеет сопоставлять состояния объектов из приложения и столбцы таблицы из баз данных.

Вы можете использовать шаблон отложенной загрузки [Fowler PoEAA], чтобы смягчить проблему больших объектов в памяти.

Успехов вам!