Планирую приложение на Yii2 + Angular2. Сервер и фронт будут разными приложениями, которые связываются с помощью REST.
0) Начинать надо с предметной области - думаю, тут хороших альтернатив нет. У меня получается, что предметная область ложится на реляционную модель, просто один бизнес-объект может быть абстракцией над несколькими таблицами. Т.е. коллекция телефонов в моделе юзера - это просто его св-во, массив, как вариант, а в представлении БД - это таблица юзера отдельно и таблица телефонов отдельно. Связь по внешнему ключу через JOIN. Но что-то тут меня смущает. Итак, буду благодарен за практический пример создания предметной области.
1) Но когда у меня есть объекты предметной области - являются ли они же и ресурсами в понимании REST? Или они не будут совпадать, так же, как доменные объекты не совпадают с их представлением в базе - таблицами? Как смоделировать предметную область и ресурсы для REST с минимумом лишних действий? Если кто может написать на примере нескольких сущностей - будет здорово, теория очень уж многозначна.
2) Если у меня есть на бекенде организованная предметная область, которая десериализуется и передаётся на клиент, будет ли это в сумме с HATEOAS большей частью предметной области для Angular приложения? Т.е. я передаю некоторый объект (ресурс) и в придачу к нему некоторые действия, которые ангуляр приложения может выполнять с этим ресурсом (может и не выполнять, может свои добавить, API ни к чему не обязывает).
Ох... архитектура - это знание о том, как мало ты понимаешь....
С одной стороны, для адекватного ответа на вопрос данных недостаточно. С другой - упоминание конкретных технологий фронта и бэка не приближает нас к ответу.
Что касается идеи начинать с предметной области - то это напрямую следует из вопроса. Ведь "доменные объекты" - это же и есть объекты предметной области. Не совсем понятно, что имеется ввиду под моделированием.
Опишите Вашу задачу - тогда можно будет конкретно с примерами обсуждать.
Мне кажется, тут происходит некоторая путаница понятий. Предметную область не нужно передавать с сервера на клиент. В разные моменты времени передаётся лишь некоторое её представление. Кроме того, не покидает ощущение, что где-то в Вашей формулировке закопан CRUD. Но если мы говорим о Domain-Driven Design, то, как правило, решаем задачу, которая в CRUD не вписывается.
Предметная область понятие весьма расплывчатое. Так что возможно мы говорим о разных вещах, но все же:
Все взаимосвязи и структура таблиц для REST не особо то будет отличаться от стандарных практик. Вам надо организовать все так, что бы этим было удобно пользоваться в рамках Yii и ActiveRecords. В БД таблицы user и phones и две модели, которые связаны между собой. И $user->phones в зависимости от hasOne или HasMany это будет объект или массив объектов. Вот такая схема и есть оптимальная для rest с yii2. Запросили телефоны, получили телефоны только или с связанными юзерами, запросили юзеров, получили юзеров с телефонами или без.
У меня складывается впечатление, что у Вас много теории в голове, но yii вы видели мельком. Потому как проблемы в Вашей проблеме нет.
Средний
Средний
Простой
Средний
