Доброго времени!
Не ожидал, что сама парадигма DDD так меня притянет, но уж так произошло.
Читая различные материалы возникли некоторые вопросы о правильности понимания.
1. Вроде как отличия Entity от Agregate понятны, но хочется понять, что понял это верно.
Например имеем сущность Product. У Product'а есть набор свойст и их значений (EAV). Получается у нас Product уже не сущность, а агрегат?
2. Свойства Product'а будут являться отдельными сущностями, или просто VO?
3. Имеея репозиторий MySQLProductRepository мы можем проводить запросы на вставку сразу в несколько таблиц, в случае использования свойств Product'а (EAV)? Или нужно обязательно городить адаптеры для разных репозиториев?
4. Насколько оправдано использовать UUID непосредственно для уникализации? А для выборок использовать обычный AI PK id?
5. Criteria собирать непосредственно в виде методов репозитория а ля active() или лучше передавать непосредственно из сервиса отдельным объектом?
6. При работе с Yii, получается мы реализовываем UserSevice реализующий IdentityInterface?
7. Можно ли использовать магию в агрегатах и сущностях?
Очередная порция вопросов о DDD
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Очередная порция вопросов о DDD
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
Re: Очередная порция вопросов о DDD
1. Да. Если есть вложенные объекты, то это агрегат.
2. Внутренности обычно делают как VO.
3. Да. Репозиторий обслуживает весь агрегат. И не важно, сколько там таблиц.
4. Можно обойтись UUID4 + timestamp вместо AI.
5. Удобнее отдельными методами getByName, geyByEmail и т.д. А для значений из формы поиска сделать DTO.
6. Да, объект Identity, дёргающий репозиторий.
7. Магия не очень удобна. Лучше явно без неё.
2. Внутренности обычно делают как VO.
3. Да. Репозиторий обслуживает весь агрегат. И не важно, сколько там таблиц.
4. Можно обойтись UUID4 + timestamp вместо AI.
5. Удобнее отдельными методами getByName, geyByEmail и т.д. А для значений из формы поиска сделать DTO.
6. Да, объект Identity, дёргающий репозиторий.
7. Магия не очень удобна. Лучше явно без неё.
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: Очередная порция вопросов о DDD
Спасибо, Дмитрий.ElisDN писал(а): ↑2017.07.22, 08:40 1. Да. Если есть вложенные объекты, то это агрегат.
2. Внутренности обычно делают как VO.
3. Да. Репозиторий обслуживает весь агрегат. И не важно, сколько там таблиц.
6. Да, объект Identity, дёргающий репозиторий.
Но ведь всё равно будет проигрыш в скорости?
Тут немного не "по человечьи" выразился. Я имел ввиду scopes Просто вопросы писал до кофе
Ну это понятно. Но вот как реализовать тогда геттеры и сеттеры для атрибутов EAV? Кроме магии ничего на ум не приходит, к сожалению...
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: Очередная порция вопросов о DDD
Получается в агрегате лучше не реализовывать обращение, как к реальным свойствам через __set() и __get()? Через $product->setValue($attrId, $value) и $product->getValue($attrId) ведь не получиться использовать ArrayAccess, что усложняет код. Или я что то не так понимаю?
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: Очередная порция вопросов о DDD
Уже более глубоко полез и разобрался почему лучше без магии) Спасибо за ответ)
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x