Какие сущности или слои должно иметь приложения такого формата?

Question

[topuserman]

Требуется разработать конфигуратор компьютера.
Мы имеем уже готовую структуру данных в БД.

Для начала, я бы хотел иметь отдельную сущность для каждой детали компьютера.

Тут сразу возникают вопросы:

Правильно ли понимаю, что в контексте DDD - это называется Entity ?
В некоторых источниках читал, что Entity - просто содержит состояние. Т.е. это одна запись из таблицы БД, со всеми его свойствами (+ может содержать какие-то геттеры), и не может содержать никакой логики.

Если это так, то что делать, если Entity - это Материнка компьютера, и мне нужен метод, который возвращает список всех подходящих Процессорров для этой материнки.

Где тогда нужно разместить метод и реализацию, который будет этим заниматься ? И как будет называться этот слой в контексте DDD ? Репозиторий ?

Дальше, возникает вопрос, если я получаю список Entity - то это коллекция именного этого типа Entity ?

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

Answer 1

[Владимир Коротенко]

Материнка.
у нее комплектующие типа
процессор
память
hdd
Sdd
usb
и прочее.

Но !

Энтити
это
Материнка.
процессор
память
hdd
Sdd

И вы уже в репозитории создаете служебный метод.
GetCompatiblyCpu возвращающий процессоры совместимые с матерью.

А уже на уровне выше вы собираете модель, которая содержит всю требуху.
База она должна быть простая

Comments

[topuserman]

спасибо.

не совсем понял, я думал Модель - это почти одно и тоже, что и Ентити. Тогда в чем их отличие ?

Что значит на уровень выше ? На уровень выше Репозитория ?

[Владимир Коротенко]

Есть Entity это модель уровня базы данных.
Простая как 3 копейки.
Есть уровень бизнес логики, там свои модели. Там уже вы строите связи. Как то совместимость, наличие на складе и прочее.

И есть последний уровень моделей. Это модели отображения. Это именно то что отдается клиенту.

Каждый уровень развязан друг от друга и в идеале знает только о нижнем уровне и то через интерфейсы.

Answer 2

[Максим]

1. DDD начинается не с базы, а с кода.
2. Entity может быть разной. Если вы говорите про анемичную сущность, то у неё есть set и get. Однако это считается не очень хорошая практика. Больше она подходит для быстрой разработки. Поэтому сущность должна быть богатой. В идеале состоять только из методов модификации убирая get и set. В таком случае вы можете закладывать бизнес правила прямо в сущности. Вы сказали, что она не может состоять из логики - это ошибочно. Хорошая сущность должна иметь логику. Пример
3. Entity ничего не возвращает. Это задача репозитория.
4. Кроме Entity есть агрегат. Вот он как раз включает в себя все детали.

Про DDD лучше читать или смотреть. Так как это достаточно обширная тема, в которой нужно разбираться не только по ответам на тостере, но и на практике.

Статья в помощь: https://m.habr.com/ru/post/61524/