Как загружать вложенные сущности в ddd?

Создать две модели, одна для чтения, другая для записи.

Как в ddd выбрать "всего" элементов?

elementRepository.Count - репозиторий это абстракция над базой данных, ее можно воспринимать как простую коллекцию, ну т.е. иметь операции добавления/удаления/поиска...
А вообще, если вы используете пагинацию, то значит вам нужны данные для отображения информации, а для этого тянуть из базы агрегаты не очень хорошая практика... Замените их на ViewModel и эти простые DTO'шки тяните из БД

Что почитать для прокачивания навыков проектирования приложений?

Не подумал бы никогда что эта книга может чем-то помочь, пока ее не прочитал!

Всегда ли объект должен валидным?

Myroslav Berlad,

а ети правила можно закинуть в Specification

Если я вас правильно понял, то в итоге у нас "на руках" должен быть ОБЪЕКТ-СПЕЦИФИКАЦИЯ, которая возможно состоит из других спецификаций и более? Что-то наподобие RegNumberIsValidSpecification, который содержит метод IsSatisfiesBy(string regNumber)? Верно или нет?

Если да, то постараюсь объяснить почему на мой взгляд это не очень хорошее решение.

Данный паттерн является не просто техническим программным механизмом, с помощью которого можно комбинировать различные условные выражения, которые позволяют строить очень сложную логику проверок.
СПЕЦИФИКАЦИЯ должна выражать какое-то понятие предметной области, а уже из простых понятий можно строить более сложные путем их объединения. Вот например, у нас есть программа для работы с клиентами, и в нашей предметной области есть такое понятие как "Любимый клиент" и соответствующее бизнес-правило, которое гласит что "любимым клиентам" предоставляется скида 15%. Понятие "любимый клиент" может, например, состоять из таких понятий как "постоянный клиент" и "надежный клиент", плюс еще какие-нибудь дополнительные условия и проверки... Когда в каком-нибудь методе мы будем производить расчет стоимости за оказанные услуги, то проверим является ли клиент "любимым", примерно так :

if (favoriteCustomerSpecification.IsSatisfiesBy(customer))
{
 // здесь вычитаем 15%
}

...

В теории, по данной спецификации, мы можем запросить из CustomerRepository список клиентов, которые являются "любимыми", передав СПЕЦИФИКАЦИЮ как входной параметр методу репозитория.

Теперь вернемся к нашей предметной области, логично ли будет запросить из DocumentRepository список документов которые имеют "валидный" регистрационный номер? В нашей предметной области даже понятия такого не существует... Проверка на корректность входных параметров, это чисто программный механизм, который никак не отражается в моделировании предметной области и соответственно не будет СПЕЦИФИКАЦИЙ, которые моделируют понятия...

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

DDD, Aggregate root без ORM, как сохранять?

Станислав Силин, ну вот смотрите, например ваша программа работает с автомобилями, у какого-то автомобиля, который у вас обслуживается на данный момент три колеса. И вот приходит новое колесо для этого автомобиля, и вы в программе добавляете к этому автомобилю новое колесо, и в это время ваш коллега тоже добавляет к этому автомобилю новое колесо, если программа следует вашей логики, то будет в базу добавлена запись(и вашего коллеги), потом для вас и вашего коллеги программа обновляет свое представление, и вы оба видите что у машины пять колес. Может быть у машины пять колес?

DDD, Aggregate root без ORM, как сохранять?

Станислав Силин,

Предметная логика, конечно я считаю, должна быть реализована в Domain Layer, а не в Базе Данных. Если два пользователя одновременно редактируют АГРЕГАТ, один добавил позицию, и второй добавил позицию в заказ, и если просто две записи добавились напрямую(как вы пишите) в БД, то бизнес-правила могут быть нарушены.

DDD, Aggregate root без ORM, как сохранять?

Станислав Силин,

В случаи когда нам понадобиться добавить новый Item для Order, то мы просто добавим Item с ключем от Order в базу напрямую(без order.AddItem(item)).

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

Всегда ли объект должен валидным?

Согласен, тоже так думаю

Как организовать сложную бизнес-логику?

Да, таблицы мне кажется очень гибкое решение, про них я еще читал в книге "Совершенный код". Также искал что-то подобное в интернете, но к сожалению ничего толкового не нашел, а все что находил относилось к тестированию ПО, искал по запросу типа: "..таблицы решений..". Если продумать все так, чтобы это вписывалось грамотно во взаимодействие с UI, то было бы здорово. Если например, существуют 200 правил, то мы бы их просто описывали и добавляли в таблицу, а дальше уже какой-нибудь наш самописный движок исполнял код как надо, т.е. мы разгружаем наш мозг, и в основном работаем только руками добавляя правила в таблицу. Это похоже на то, как предлагал Ptolemy_master, чтобы уйти в сторону декларативности, но если мы создаем какой-то универсальный процессор обработки правил, то всегда появится куча "НО", которая заставит нас добавляет всякие исключительные случаи, тогда либо теряется универсальность, либо возрастает сложность!
Вообщем, я пока остановился на таком решении, буду использовать паттерн СОСТОЯНИЕ, где в роли стейт- машины будет Presenter, т.е. внешне View будет вызывать методы Presenter'а, но в методе не будет много разных if'ов, вместо этого он будет делегировать вызовы текущему объекту State...

Как организовать сложную бизнес-логику?

Спасибо. Действительно интересный ответ, вопрос только в том что должно лежать на пересечении? Я так понимаю там может лежать метод(action/callback)? Верно?

Как организовать сложную бизнес-логику?

Что касается ухода в сторону декларативности, то идея мне очень нравиться. Вопрос только в том что и где декларировать? Было бы здорово описать все связи и правила и отдать их какому-нибудь процессору, который бы весь этот комбайн запускал...
Допустим возьмем Веб, я там использовал для UI библиотеку VueJS, это наподобие React'а, так вот, там мы описываем декларативно графический интерфейс в зависимости от состояния объекта, когда меняется свойство объекта, то UI изменяется сам так, как ему надо без нашего вмешательства. Но тем не менее, зависимости свойства от других свойств и их значений - остается. Если мы меняем третье свойство, что должно произойти если оно зависит от первых двух и их конкретных значений? Опять в методе получается много if'ов...

Как поместить объект в 2 переменных, так чтобы при изменении в одной, объект не менялся во второй?

Если используешь jQuery, то можно так: var objB = $.extend(true, {}, objA);

Как пропарсить количество символов после точки?

Тогда условия задачи неверны, т.к 1.1 == 1.100 => true