Максим: Должны ли в сущность пользователей входить их адреса? Если нет, то значит ли это что при необходимости получить адреса юзера нужно запрашивать [GET] system/api/v1/user/id, выбирать ->addresses и инициализировать репозиторий?
Максим: я понял идею, только оптимизма это не добавило :) Сложно было бы реализовать такую систему.
Не хочу плодить вопросы, как в контексте DDD реализовать API? Я имею ввиду что при обычной работе с базами есть сущности которыми просто манипулировать, а API в основном отдает некую связку сущностей, получается, нужно разбивать ответ?
Максим: я в комментарии дополнил и вроде информации должно хватать.
Есть User model для работы с 1 категорией пользователей (текущая система).
Есть User model для работы с 2 категорией пользователей (другая система).
Вопросы:
1) Юзеры, к примеру, объединить нельзя, работа ведется по отдельности.
Так и называть сущности UserSystem1Model, UserSystem2Model?
2) Товары, к примеру, объединить надо, но только частично.
Как в данном случае выделить сущность не понятно. Чтобы было ясна ситуация, предлагаю посмотреть на демонстрацию inner join (не в sql-контексте).
Антон Рейтаровский: наверняка используете консоль. Вроде чтобы она начала видеть файлы, опенсерверу нужно закинуть path.txt в настройки, где указать пути для composer/bin
На счет yii2 много читал последнее время, знаю что он RAD и это все определяет. Так уж вышло что пока symfony 3 только в стадии рассмотрения и начать ее использовать скилов не хватает.
Yii2 di действительно очень странный.
Сразу скажу что проект уже по большей части реализованный, просто мне не особо нравится как все работает поэтому хочется на будущее узнать больше. А пришел к DDD потому как интуитивно начал делать слоеную архитектуру. Т.е. подобие, конечно же :)
Есть 2 системы: magento 2 которая является "базой" для магазина и yii2 который является "интерфейсом" с расширенным функционалом (магазин очень нестандартный). Фрэйморк работает со своими сущностями и с сущностями мадженты (через API). Модели и формы стандартны, для API пришлось написать свою (swagger оказался ужасным) либу (1 слой - обертка для guzzle с авторизацией https://github.com/springimport/magento2-api-v1 , 2 слой - базовая либа https://github.com/springimport/yii2-magento2-activeapi , есть еще 3 слой который является адаптером ко 2, но он не вынесен отдельно). На счет кода догадываюсь, поэтому можно не вчитываться :)
И если для базовых вещей применение DDD более-менее понятно, то как его использовать с 2 одинаковыми предметными областями - не понятно. В моем вопросе пример про пользователей.
Столкнулся с тем что не получится скомбинировать логику с кэшированием. То, что кэш работает уровнем выше приносит плюс в виде понятной архитектуры, но, например, нельзя вызвать methodA() который бы вызывал кэшированный methodB(), поскольку они ниже уровня кэша. MethodB(), например, быстро устаревает и кэшировать его нет смысла.
Постоянно думаю на счет использования наследования, адекватно ли это?
Бесит.