Как использовать DDD?

Question

[Дмитрий Башинский]

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

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

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

Опишу свой домен
У меня есть страница, у страницы есть комментарии, эти комментарии могут оставлять пользователи.


Я реализовал метод у страницы для добавления комментария и дальше создал обработчик команды на добавление комментария. В команде мне приходит


И если делать по самому оптимальному способу то я бы просто добавил 1 строку в таблицу Comments через EF, но если идти без читинга, а через домен, то я достаю страницу по Id и в нее мне нужно добавить коммент, в доменном комменте у меня есть Author и я беру теперь ещё и юзера по id и добавляю в этот коммент.

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

Сразу хочу сказать что мне уже предлагали вместо того чтоб ссылать на другую сущность (юзер к примеру) мне лучше использовать UserId когда я так сделал я получил копию схемы своей БД, но не свой домен

Answer 1

[Евгений Ромашкан]

Пусть статья и комментарии будут разными агрегатами. У комментариев будет свой домен.

Можно в контексте комментариев сделать свой класс статьи( Article ). Он даже не будет сущностью:

class Article {
  private UUID id;
  
  private CommentsRepository comments;
  
  ...
  
  public void function addComment(commentData: commentData) {
    this.coments.add(new Comment(this.id, commentData));
  }
}

В контексте комментариев не обязательно нужна статья - нужен только её идентификатор.
Также в контексте комментариев вовсе не нужны данные пользователя - только его идентификатор. Идентификаторы достаточно стабильная информация чтобы не бояться их шарить.

И да, в данном случае мы имеем дело просто с декомпозицией системы, к реальному DDD это мало отношения имеет, потому что domain-driven-design, он domain-driven за счёт того что конексты обсуждаются с бизнесом, а не придумываются разработчиком, в данном случае мы просто берём оттуда немножко терминологии потому что она уже стала довольно общей.

Comments

[Дмитрий Башинский]

Евгений Ромашкан
Я понял Вашу идею, но мне не нравится что у Вас в домене используются репозитории.
Я думал DDD о том, чтоб отделить домен от внешнего мира, описать чистые обьекты, и их функции (Простое ООП), а дальше этот мирок завернуть в сервисы и тд, разве нет?

[Евгений Ромашкан]

Дмитрий Башинский, Интерфейс репозитория - не инфраструктура, реализация - инфраструктура. Просто для одной сущности редко бывает несколько реализаций репозиториев, поэтому обходятся просто без них (пока репозиторий один) :)

Я думал DDD о том, чтоб отделить домен от внешнего мира, описать чистые обьекты, и их функции (Простое ООП), а дальше этот мирок завернуть в сервисы и тд, разве нет?

Классический DDD это коллаборация с доменными экспертами для нахождения общей терминологии в сложной доменной области и всякое такое.
В контексте отделения домена от инфраструктуры речь идёт о принципе направления зависимостей, то есть модули, которые меняются реже, не должны зависеть от модулей которые меняются чаще. Интерфейс репозитория - штука, таки, стабильная.
Бизнес правила такая штука тоже инкапсулирует хорошо.