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

Question

[red_gorilla]

public class Order
{
   List<OrderItem> Items {get; private set;}

   public AddItem(OrderItem item)
   {
       //логика  добавления

       items.Add(item);
   }
}

Следуя методологии DDD вся логика домена находится внутри домена и не выносится в отдельные сервисы. Вопрос в том как сохранять изменения корня агрегации не используя ORM, ну или используя microOrm - Dapper. Как делаете вы? как будет реализован метод OrderRepository.Save() или Update() если использовать паттерн repository или как будет реализована команда AddItemToOrderCommand если использовать паттер CQRS.

Comments

[Антон Каракулов]

Тоже озабочей темой правильного сохранения изменений в DDD, в том числе и для корня агрегации. Вроде как методологически через репозиторй нельзя делать `save/update`, только `add/delete`.

Многие на эту тему говорят об использовании концепции UnitOfWork, которая должна решать данный вопрос вроде такого:

OrderRepository.add(Order)
UnitOfWork.save()

Так что если у вас появилась новая информация буду рад услышть.

Answer 1

[Станислав Силин]

А что вам мешает сделать типичный репозиторий, часть методов которых будет переопределена или будут добавлены новые отсностиельно базового для роботы на прямую с SQL?

Comments

[red_gorilla]

Можно на примере выше, вот в order мы добавили новый item, как его сохранить\обновить в репозитории? (без orm)

[Станислав Силин]

Вы хотите чтобы я написал кусок SQL-я, который положит ваш Order в базу?

[red_gorilla]

Поясню =).. Например, OrderRepository.GetById(666) вернул вам Order со всеми его Items, потом вы в ордер добавили новый айтем order.AddItem(item). Как вы все это дело потом сохраните в базу?

[Станислав Силин]

Без ORM можно сделать из Order ActiveRecord, т.е. захренячить SQL в модель, но это очень плохая и печальная идея. Можно пойти другим путем и забыть про наш ActiveRecord и Order с его AddItem в принципе. В случаи когда нам понадобиться добавить новый Item для Order, то мы просто добавим Item с ключем от Order в базу напрямую(без order.AddItem(item)). В таком случаи мы рассинхринизируем базу и клиент, но если нам это уже не важно, то пофиг, если важно, то мы всегда можем достать оновленый Order из базы заново, ну либо извращаться с AddItem.

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

[ddd329]

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

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

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

[Станислав Силин]

ddd329,

сумма заказа не должна превышать определенный лимит...

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

обновлять АГРЕГАТ полностью в Базе Данных

нам никак не поможет(и не возможно в принципе).

А если вы предполагаете, что эта провекра будет внутри order.AddItem(item), где order часть DAL слоя, то вы сами себе стреляете в ногу...

[Станислав Силин]

нам никак не поможет(и не возможно в принципе).

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

[ddd329]

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

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

[Станислав Силин]

ddd329, ну так я ж пишу

но если нам это уже не важно, то пофиг, если важно, то мы всегда можем достать оновленый Order из базы заново

[ddd329]

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

[Станислав Силин]

ddd329, типа order.AddItem(item) вас от этого спасет.

Answer 2

[Иван Филатов]

Тогда вам придется (вместо Get и Save) реализовать репозиторий с методами

T Find(Guid id);
void Add(T item);
void Update(T item);
void Delete(T item);

Comments

[red_gorilla]

в том то и дело, как реализовать метод Update в OrderRepository для Order (пример выше), пробегать по всей коллекции Items и не существующих добавлять а измененные item обновлять?

[Иван Филатов]

red_gorilla: ORM умеет следить за изменением состояния как корневого, так и вложенных entity.
Как это реализовали в EF, NHiber и т.д. можно я думаю посмотреть в исходниках.
Но это вообще хороший вопрос, как best practices, сделать такую штуку. И делать оптимальный UPDATE только изменившихся полей и т.д.

Я бы не заморачивался и взял EF.

[red_gorilla]

Просто бывают ситуации когда EF, NHiber не подходит из за медленности работы

Answer 3

[ddd329]

Без ORM, есть простые шаблоны. Твой репозиторий имеет метод Save, не важно обновил или создал новый АГРЕГАТ, все это передаешь методу Save, т.е. один метод вместо двух - Add и Delete. Допустим, ты обновляешь АГРЕГАТ, который состоит из трех сущностей, а в базе существуют три таблицы, т.е. каждая сущность маппиться на свою таблицу. Та сущнсость которая представляет корень АГРЕГАТА, будет использовать оператор UPDATE в SQL запросе, а дочерние сущности надо удалить (DELETE FROM..) и вставить заново(INSERT INTO). Все это делается в одной транзации базы данных, никакой вам Unit Of Work не нужен...

Попробуйте...