ddd329

Когда твои данные дойдут до ApplicationLayer, то служба этого уровня, должна достать агрегат из репозитория, и над этим агрегатом произвести действия на основе входящих данных. Например, если отредактировали фамилию пользователя, то:
1. var user = userRepository.GetById(777);
2. user.LastName = inputData.LastName;
3. userRepository.Save(user);

В таком духе...

У меня есть сущности и репозитории к ним.

Репозитоии создаются для сущностей, которые являются корнем агрегации.

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

Загружать вложенные сущности нельзя, потому как:
1. Сущность не может обращаться к репозиторию, она может иметь только ссылки на другие сущности и на объекты-значения;
2. Грузить надо сразу целый граф безо всякой отложенной загрузки.

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

Вот как раз для этого агрегаты и нужны

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

Сущности и агрегаты нужны для реализации бизнес-логики, чтобы ты не смог в базу данных записать недостоверную и/или противоречивую информацию, и все!
На экране ты отображаешь не сущности и агрегаты, а скорее информацию о них... Когда ты думаешь о выводе данных на экран, то не должен даже мыслить агрегатами, потому как агрегаты являются единицами изменения, а не порция для отображения.
Поэтому можешь обращаться на прямую в БД с запросом выдать тебе информацию, или создать отдельную Модель Чтения, и через ORM читать данные.

Создавать сущность LocalizedDisease не имеет смысла, так как не реализует новое поведение. Вообще сущность это в идеале только поведение, и не важно какие у него данные, то есть принцип здесь - "Говори а не спрашивай"

Привет!

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

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

Как быть если ошибка в нескольких атрибутах сущности?

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

Дублировать валидацию на клиенте и сервере не хочется

Дублировать валидацию можно, если она общеизвестная, например ФИО или email-адрес, зачем перепадать эти значения на сервер, когда в браузере можно выполнить их полноценную валидацию, что повысит время отклика UI. А если логика специфичная, что чаще и бывает, то бизнес-правила должны "лежать" на уровне домена, и не выше.

В общем, мне известно два варианта создания сущностей: используя только публичный конструктор, или используя фабрику(factory). Если я вас правильно понял, то у вас имеется форма с полями для заполнения их значениями, которые являются атрибутами какой-то сущности?
Здесь могут быть два сценария, первый: когда сущность, а точнее АГРЕГАТ, извлекается из репозитория с целью редактирования, то здесь все так, как вы описали выше: неверное значение атрибута - выбрасываем исключение.
И второй сценарий - создание сущности. Нигде нельзя получить доступ к невалидной сущности, созданной с помощью оператора new DomainObject() кроме как фабрики. Поэтому создавайте фабрику, которая позволяет строить вашу сущность, а точнее АГРЕГАТ, по шагам. Для этого примените паттерн проектирования СТРОИТЕЛЬ (Builder). В конце вызовите метод Build(), который и вернет вам валидный АГРЕГАТ.
Что качается промежуточных результатов "строительства", то для их получения используйте паттерн проектирования СНИМОК (Memento), например вот так: var snapshot = domainObjectFactory.GetSnapshot();, где snapshot обычная DTO-ошка, которая содержит значения атрибутов сущностей и списки ошибок, валидность и т.д. Ну а дальше смотрите сами как быть, если вы на клиента передаете ViewModel-s, то используя snapshot создавайте модели представления и дальше их на UI пользователя.