Задать вопрос
myks92

Максим

Нашёл решение — пометь вопрос ответом!
Ответы пользователя по тегу Проблемно-ориентированное проектирование

  • Entity vs Value Object DDD?

    myks92
    @myks92
    Нашёл решение — пометь вопрос ответом!
    1. Отличие VO от Entity это то, то её можно идентифицировать по Id. Так же структура VO не меняется с течением времени. Например, VO Email где бы то не был будет одинаковым и его логика долго не поменяется.

    2. Тут зависит от того как вы используете эти Group. Если вам где-то в вашем приложении эти группы нужны, то их лучше создать как отдельную сущность/агрегат. Но можно и сделать их VO в сущности Ticket и хранить только ID Group, либо непосредственно название группы. Все зависит от того как вы работаете с этим в вашем контексте. Например, в контексте справочников Group может быть сущностью и это нормально. А в контексте Ticket можно хранить только ID или само значение.
    Ответ написан
    8 комментариев
    8 комментариев

  • Логика в командах CQRS?

    myks92
    @myks92
    Нашёл решение — пометь вопрос ответом!
    Вы путаете команду и событие.

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

    Событие: пользователь создан, пользователь удалён, пароль пользователя изменён, пароль пользователя сброшено, пользователь отредактировать, товар продан и т.д.

    Команду «отправить уведомление» вызывать в другой команде нельзя. Команды не могут вызывать друг друга напрямую. В этом случае у вас есть событие «пароль пользователя изменён». На это событие вешается подписчик Уведомления. Этот подписчик отправляет сообщение напрямую, либо вызывает такую же команду, но команду уведомлений.

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

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

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

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

    Статья в помощь: https://m.habr.com/ru/post/61524/
    Ответ написан
    Комментировать
    Комментировать

  • Как правильно реализовать CRUD при работе с DDD и Yii2?

    myks92
    @myks92 Куратор тега Yii
    Нашёл решение — пометь вопрос ответом!
    1. В DDD подразумевается предметная разработка. Соотвественно CRUD тут не совсем правильно делать. Тут нужно работать с UseCase: создай товар, удали товар, оплатить товар, архивировать товар. Это уже больше чем CRUD.
    2. Во фреймворке делайте своё ядро, которое принимает DTO. Запихиваете данные в DTO далее передаёте в сервис, обрабатываете данные и пихаете через Repository в базу. В принципе все просто. Можете посмотреть курс Елисеева Дмитрия по работе с интернет магазином. Если говорить о примерах, то вот, правда на симфони.

    Так же есть пример из самого магазина
    Ответ написан
    2 комментария
    2 комментария