На чём лучше прокачивать архитектурный навык разработки моделей предметной области и принципов DDD вообще?

Question

[olijen]

Лично для себя пишу тестовое приложение для повышения архитектурного навыка и практик работы с автоматизацией окружения.
Сейчас стою перед выбором технологий для самого приложения, которое позволит "пощупать" хорошие архитектурные принципы.
Приложение типа SPA, Angular 2 на фронте.
Сервер планируется в качестве API, возможно REST.
Мне казалось, что я достаточно хорошо разобрался в теме архитектуры ООП приложений, но на последнем этапе, уже установив фреймворк, подняв виртуалку с окружением, установив ларавель, начал читать "залпом" существующие статьи про архитектурные подходы, и, надо сказать, совершенно перемешал те знания и семантические связи, которые имел касательно архитектуры. Да и читая мнение разных людей, прихожу к выводу, что нет единого мнения и (или) понимания. Одни споры и разговоры об одном, но по разному. По сути, даже единого согласия о DDD не увидел, каждый как то сам себе его понимает...

Как то не обратил внимания, что родная работа с данными в Laravel ведется с Active Record. С ним я хорошо знаком в Yii, да и с нуля сам реализовывал в своём мини-фреймворке. Понимаю, что это антипаттерн в плане того же принципа единой ответственности. Хотелось поработать более плотно с DataMappers и вообще с новой ORM - Doctrine 2, к : пока писал примеру. И тут на тебе - читаю, что дата-мапперы в контексте stateless - антипаттерн а Doctrine - вообще мало совместим с пхп - это из статьи на хабре. Т.е. REST не совмещается уже.
Планировал перейти от Data к Domain Driven Development - опять же в целях обучения. Как это реализуется на Laravel? Или может мне с такими запросами и не он нужен? Начинаю приходить к мнению, что выбор в сторону ларавель - не более чем недостаточная информированность, т.к. читая о симфони кажется, что на нём будет лучше оттачивать практики хороших абстракций и разработки моделей предметной области.

Кроме того, установленный ларавель с его фасадами фасадами как то не сильно сдружился с PHPStorm. Да и начиная с фронт-контроллера нет никакой возможности перемещаться по классам и изучать фреймворк (как в Yii, к примеру). Вроде, это как то решается какой-то доустановкой, которая продокументирует код, но пока не смог реализовать.

Не стоит писать что-то абстрактное типа "всё зависит от проекта", "архитектура не привязана к фреймворку" ... Очень даже привязана. А философствовать на тему архитектуры ПО я, как и еще многие, могу часами и днями. Но когда доходит дело до разделения обязанности между компонентами и реального моделирования... Внезапно всё не так однозначно.

Answer 1

[xfg]

Любой фреймворк с инверсией зависимостей подойдет. На Symfony и Yii2 точно можно сделать. На русскоязычном форуме Yii по теме DDD очень много обсуждений. Но если не увидели единого согласия по DDD, то скорее всего не читали книгу Эванса или Вернона. Если так, то лучше начать с кого-нибудь из них.

Многоуровневая архитектура рассказывает нам о слоях presentation, application, domain и infrastructure. С однонаправленным потоком данных. Нижестоящий слой, никогда не должен вызывать вышестоящий. Это значит, что к примеру можно выбросить presentation слой и не придется ничего изменять в оставшихся 3.

Фактически выходит, что в любой момент можно выбросить фреймворк и заменить другим, так как это presentation layer в многоуровневой архитектуре. Можно даже сначала написать application/domain, проверить их юнит-тестами, а только потом уже задуматься о фреймворке. Application/domain слои никогда ни при каких обстоятельствах не должны вызывать методы фреймворка. Контроллеры фреймворка работают с доменной моделью, через вызовы методов application layer.

Соответственно, при миграции на другой фреймворк, всё что потребуется, это переписать контроллеры (методы очень простые 1-5 строк) и реализации классов в infrastructure layer если вы завязывали их на фреймворк. Хотя лично я бы, не советовал этого делать. Лучше найти/написать отдельные библиотеки/компоненты под инфраструктурный слой, тем самым облегчив себе жизнь в будущем, когда фреймворк умрет или при очередном релизе мажорной версии.

Symfony под DDD наилучший выбор, он компонентный, можно подтянуть только то, что нужно. С другой стороны Yii2, он монолитный и вы затяните Active Record и кучу всего еще, чем не будете пользоваться, но джуниор придет и обязательно понавызывает AR или чего-нибудь еще в application/domain слоях, чего вы явно не ожидаете. Поэтому в случае с Yii2 нужен будет тотальный контроль. :)

Про Laravel не пишу ничего, так как не работал с ним. Но судя по беглому просмотру документации, никаких проблем сделать на нем DDD также нет.

Comments

[olijen]

Посоветуете статьи по проектированию доменной логики и многоуровневой архитектуры? Желательно, без привязки к фреймворку. Очень хочу прочитать книги по DDD, но судя по тому, как спорят читавшие их люди, они всё равно не определились, следовательно надо будет нырнуть в книги с головой и практикой, что перечеркнет прочтение моих текущих книг. Конечно, слабый аргумент, но пока хотелось бы практики. Уверен, что теорию можно объяснить в сжатом виде.

[xfg]

Лучше скачайте/купите Implementing domain-driven design, вот эту красную книжечку https://vaughnvernon.co/?page_id=168 Это практика, не теория. Когда я изучал тему, прочитал изначально, только раздел про Entity вдохновился и пошел делать эти сущности. Затем возник вопрос, а как сделать доменный объект из нескольких Entity и пошел читать про Aggregate. Затем, как это всё сохранить и прочитал про Repository. В итоге, со временем по кускам прочитал почти всю книгу. Любую тех. литературу нужно так читать:

1. Делаем проект
2. Возникает вопрос
3. Ищем решение в книге
4. Возвращаемся в пункт 1

Статьи я читал как дополнение, просто гуглил, куча разных блогов/сайтов/stackowerflow и прочего. Но это все разрознено по какому-то конкретному небольшому вопросу, а так чтобы ввиде цикла статей о проектировании доменной модели и многоуровневой архитекруты не встречал.
Но если хотите, то https://lostechies.com/jimmybogard/category/domain...
Но лучше пишите приложение, ищите решение в книге и гуглите, в большинстве случаев гугл вас все равно будет отправлять на какие-то конкретные статьи из этого блога, там много по теме DDD. Это продуктивнее и быстрее, чем выискивать какие-то конкретные статьи.

Также посмотрите тестовое приложения на DDD https://github.com/citerus/dddsample-core/tree/mas... и примерно поймете, как нужно организовывать код, что куда складывать. Пример на Java, но зная PHP можно примерно понять, что там и как.

В любом случае, вы будете делать и переделывать сделанное, так как ваши знания будут постепенно расширяться. Сразу круто не получается ни у кого. Даже сейчас, если вы не знаете ничего, всё равно пишите код. Вам нужно создать ваш первый доменный объект? Отлично, откройте упомянутую выше книгу и прочитайте раздел про Entity. И сделайте её. Для этого не нужно читать всю книгу.

[olijen]

xfg: Большое спасибо. Я согласен, надо дело делать. Ответы мне помогли упорядочить имеющиеся знания и пересмотреть заблуждения, теперь возьмусь за практику. Да и от настройки виртуальной машины уже глаза выпадают и душа плачет, пора код писать =)

[Myroslav Berlad]

olijen: вот вам как пример с кодом: williamdurand.fr/2013/08/07/ddd-with-symfony2-fold... и чутка сложней пример: https://jorgearco.com/ddd-with-symfony/
Советую со второго примера развернуть проект с репозитория (если лень будет кликнуть в статье https://github.com/jorge07/ddd-playground). Как писали выше почитайте Вернона и Еванса, они дадуть хорошую почву

Answer 2

[Тимур]

Посмотрите записи вебинаров Дмитрия Елисеева, "Интенсив ООП" - очень рекомендую
www.elisdn.ru/oop-week

Answer 3

[Алексей Анисимов]

Doctrine 2 очень даже хороший инструмент.

Я бы вам порекомендовал использовать фреймворк Symfony 3. На PhpStorm поставить плагин Symfony plugin и PHP annotations.

Comments

[olijen]

Подскажите 2 вопроса? 1. Есть ли где-то готовая сборка для вагрант - в стиле vagrant up, vagrant ssh, composer create-project и поехали знакомиться. 2. ОЧЕНЬ интересует вопрос производительности. НЕ появится ли больших проблем, если речь зайдёт о высоких нагрузках? Много читал о перегруженности Symfony. С другой стороны, Zend еще в несколько раз больше, и ничего...

[olijen]

И кстати, так же слышал, что Symfony очень уж тормозит на виртуальной машине, хотя не понял из за чего.

[shaqster]

olijen: Тормозит симфони в дев режиме, потому что каждый чих логгируется и профилируется. Проблема решается покупкой SSD. В прод режиме все летает и на обычном диске.

[Алексей Анисимов]

Vladyslav Sats: php7 работает существенно быстрее, чем php5.6 (и памяти ест в 2 раза меньше) Опять же в симфони есть кэширование, и при первом открытии страницы время загрузки будет намного больше, чем последующие.

[Алексей Анисимов]

olijen: 1. Готовых сборок для вагрант не искал (надо погуглить). 2. Единственное, что может тормозить - это работа с базой данных, поэтому всегда в запросах джойните все что нужно. Пример, если вы достали новость и обратились к связи категория $news->getCategory(), то Доктрина сделает дополнительный запрос и вытащит данные для категории. Если у вас будет выводиться таблица с 100 строками новостей и названий категорий, то Доктрина сделает 100 дополнительных запросов. Если при выборке новостей заджойнить категории, то лишних запросов не будет. И в настройках соединения с БД всегда указывайте IP, а не хост (намного быстрее работать будет).

[Никита Киселев]

Низкая производительность может быть связана с синхронизацией папок между хостом и виртуальной машиной. На linux прекрасно настраивается NFS https://www.vagrantup.com/docs/synced-folders/nfs.html

[s5656]

olijen: >Zend еще в несколько раз больше

Только вот Zend без какого-либо кеширования работает в 10 раз быстрее, чем Symfony из коробки с кешированием всех его конфигов, сущностей итп...

Да и что значит больше? Объем файлов? Никто не заставляет ставить все-все-все модули фреймворка, ставите только те, что используете.

Answer 4

[mitaichik]

Напишу то что вы происили не писать.

DDD с фреймворком ну никак не связан. DDD про то какой объект бизнес-логики за что отвечает, как построить взаимосвясь объектов. Как перенести модель из реальной жизни в объекты и их методы. Это про бизнес-логику, бизнес уровень. В меньшей степени - про растаскивание по слоям, по уровням. В любом случае, для него не столь важно на какой инфраструктуре (читай - фреймворке) вы будете это реализовывть.

В вашем же вопросе намешано все вместе.

Comments

[olijen]

Спасибо. Да, намешано. Разгребаю месиво. Если посоветуете, как ускорить процесс - буду признателен.

[Константин]

а на мой взгляд плохой фреймворк с протекающими абстракциями будет только мешать делать нормально. по этому параметру симфони точно будет лучшим выбором - он меньше всего навязывает архитектурных решений пользователю

[s5656]

Константин: шутки шутить изволим?)

[Константин]

s5656: да нет вроде, подискутируем на эту тему?

[s5656]

Константин: да, уточнить стоило, что мое возмущение вызвало утверждение, что "симфони меньше всего навязывает архитектурных решений пользователю"...

Ведь там если что чуть не так сделал, отошел от канона и все, куча проблем.
Взять тот же Zend, вот тут да, никаких ограничений, только рекомендации.

[Константин]

s5656: не знаю о чем вы, почти всё из симфони мне удаётся использовать без самой симфони. доктрина, разве что, голову морочит. а про зенд - согласен, я скорее говорил о всяких поделках вроде уии или ларавела, которые сами по себе один большой антипаттерн

[s5656]

Константин: а, в таком случае если, то да, согласен. Я говорил про Sf "из коробки". Хотя если сравнивать с Yii или прочими Laravel'ами, то да, Sf годный даже из коробки.

Answer 5

[jacob1237]

Как это реализуется на Laravel? Или может мне с такими запросами и не он нужен?

Никак не реализуется

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

Для этого существует плагин Laravel IDE helper.

DDD - просто подход к конструированию архитектуры приложения, его можно реализовать с помощью любого фреймворка.
Другое дело что некоторые фреймворки/библиотеки могут существенно упростить применение такого подхода.

Чтобы полноценно работать по DDD, Вам необходимо как можно больше абстрагироваться от кода, ответственного за техническую часть (работа с БД и прочее). В этом как раз помогут паттерны Repository, UnitOfWork, DataMapper и т.д.

Эти шаблоны уже реализованы, например, в ORM Doctrine. В Laravel же по-умолчанию в качестве слоя БД используется ActiveRecord, который применяется преимущественно в целях RAD (rapid application development).

Если очень хочется Laravel, можете попробовать AnalogueORM. Это DataMapper-надстройка над Eloquent. Все остальное придется реализовывать ручками.

Поэтому если хотите начать работать полноценно и сразу, берите Doctrine 2 (либо Hibernate для Java, либо SQLAlchemy для Python и т.д.) и что-то в придачу к нему (тот-же Symfony или любой другой веб-фреймворк с инверсией контроля).

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

Comments

[olijen]

Спасибо. Скажите, а можно использовать ActiveRecord, но более мудро. Т.е. отделить модели предметной области в отдельные классы, а ActiveRecord оставить, как модель таблицы в базе данных? А чтоб какой-то маппер их связывал, заполнял AR из модели и сохранял. Плюс реализовать сервисный слой, который будет использоваться контроллерами, а внутри него будет связь взаимодействия AR и предметной области. Т.е. вопрос типа "как правильно использовать Yii2\Laravel", не в контексте RAD? Или не стоит так напрягаться и выдумывать? Просто использование Yii2, к примеру, мне бы сэкономило изучение доков нового фреймворка, а AR, хоть и анти-паттерн, всё же, наверное, можно его использовать с умом в хорошей архитектуре, я думаю.

[jacob1237]

Технически возможно. Но тогда Вы потратите очень много времени чтобы написать то, что уже написано (целым сообществом). Рекомендую все-таки не париться с этим, а взять что-то уже готовое.

Так будет гораздо проще и быстрее (несмотря на то, что придется изучать новую документацию), если Вас интересует только изучение самого подхода DDD.

Как только попробуете, освоитесь, тогда уже будет проще понять хочется ли Вам двигаться "вглубь" самих технологий.

Answer 6

[Unknown Hero]

Реализовывал принципы DDD на разных технологиях от Yii-1 до ASP.NET.
Тут главное уметь разделять нужную логику в нужный слой. Иногда нужно отступить от мануала вашего фреймворка и дописать свой велосипед. Но потом это окупается.

По Data Access Layer могу сказать, что нужно использовать паттерн Repository. В качестве основной реализации использовать родную для фреймворка ORM, затем всё равно так или иначе будете отказываться от ORM и писать более низкоуровневые запросы.

По фреймворку - Lumen. Это Laravel для stateless REST API.

О том как лучше понимать DDD. Кроме классических книг по этому вопросу могу посоветовать в поиске github ввести DDD или domain driven design. Там множество разных примеров на разных технологиях.

Comments

[olijen]

Спасибо. Правильно ли я понимаю, что не обязательно отказываться от ActiveRecord в Yii2, например, а хранить слой доменных объектов отдельно в самописных классах, используя AR, как модели ТАБЛИЦ, а предметную модель, как ... предметную модель? Смогу ли я в случае чего отказаться от AR в пользу другой ORM, или сразу... предсказать? И странный вопрос. У меня есть книга по Yii2 и там очень хорошо и аргументировано описана разработка приложения через тестирования с отделением предметной области (Марк Сафронов). Но там нет ничего о REST. Если я просто "проигнорирую" различные способы работы с формированием HTML на сервере, переложив это на client framework, и организовать таким образом по хорошим практикам из книги REST stateless, или у меня получится просто API с RPC?

[Unknown Hero]

Не стоит мешать в коде ORM и предметные модели. У вас должен быть слой Data Access и в нём вы должны хранить репозитории (repository pattern). В идеале ваш Data Access Layer должен состоять из интерфейсов репозиториев ( IUserRepository, ICommentRepository and etc) и их реализации для конкретного инструмента ( PDOUserRepository, DoctrineUserRepository and etc). Всё что делает репозитории это дают удобный способ общаться с базой данных скрывая инструмент который реализует это общение. Так же стоит ознакомится с паттерном Unit of Work.

Далее вы уже можете делать Business Layer в котором вы уже расписываете каждый Domain. Слой бизнес логики ничего не должен знать о Doctrine, PDO или других инструментах, он должен делать простые запросы к хранилищу ( $this->userRepository->create($userDomain) или $this->commentRepository->getAll() ). При этом реализовав один репозиторий на Doctrine вы со временем сможете заменить его на реализацию с помощью PDO или вообще другого источника данных, а код бизнес логики так и не поменяется.
Для всего этого конечно нужно использовать IoC.

По поводу инструментов, берите нативный для framework'a инструмент (yii - ActiveRecord, Symfony - Doctrine ... ) и делайте реализации репозиториев сначала на этих инструментах. Уделите особое внимане проектировки интерфейсов репозиториев и вы получите нужный результат.

REST, MVC , RPC и прочие это всего лишь слой представления. Можете игнорировать, можете не игнорировать. Если вы правильно сделаете Business/Service/Application Layer то потом у этого приложения будет очень легко поменять слой представления. Так однажды я делал проект на Laravel и мне пришлось от MVC уйти в REST API. Миграция заняла чуть меньше недели, так как нужно было просто вызывать нужную бизнес функцию в нужном роуте и всё.

Для REST API я всё же рекомендовал бы Lumen.

[xfg]

olijen: Отказываться не обязательно. Но и использовать смысла мало. Репозиторий всё равно должен возвращать доменный объект, а не AR модель, так на кой черт она вам нужна? Из данных создать AR модель, затем из AR модели создать доменный объект? Смысла ноль, лишнее потребление ресурсов, излишняя зависимость инфраструктуры от фреймворка. Захотите откатиться с этого фреймворка - будете переписывать все репозитории, оно вам надо? Сделайте своё небольшое решение, которое будет напрямую заполнять доменный объект данными из базы и раскладывать доменный объект в данные для сохранения в базу. Если вам не принципиально хранить данные в реляционном виде в куче плоских таблиц, то не очень сложно написать реализацию для хранения их как иерархических структур в виде JSON объектов. Вон Вернон пишет как это делать в PostgreSQL. В MySQL естественно плюс/минус тоже самое. Если принципиально, то попробуйте прикруть, хотя бы Doctrine, так как свой костыль будет написать уже довольно сложно, а собирать/разбирать доменные объекты руками, это долго. Но я бы не терял на всё это время, когда можно сделать гораздо удобнее, чем подход из 70ых годов прошлого века.

Answer 7

[Илья Толлю]

Как упоминают авторы других ответов, очень важно разделять задачу на части со сфокусированными зонами ответственности. Важно держать под контролем их взаимопроникновение, определять, кто от кого должен зависеть, а кто нет. И каким образом всё это можно согласовать с необходимыми характеристиками разрабатываемой системы. Иначе говоря, древний принцип "Разделяй и властвуй" и его IT-интерпретация "Single Responsibility Principle" - наше всё.

В частности, решая задачу, вписывающуюся в область применения DDD, мы должны выделить ядро, которое моделирует определённый ограниченный контекст. Вероятнее всего, также мы должны подумать о разделении обработки команд и запросов. Потому что команды означают изменение состояния предметной области, всякие валидации, транзакции, консистентность и прочее. Запросы же означают иное представление данных, эффективный доступ на чтение, инвалидацию кешей и т.д., и т.п.

Так от чего же должно зависеть DDD-ядро? Должно ли оно зависеть от конкретной реализации БД или ORM? От того, какие таблицы присутствуют в Вашей реляционной СУБД?
Или от протокола HTTP? Или, допустим, от конкретной файловой системы? Эти вопросы являются скорее риторическими. Поиск ответов на эти вопросы, а также подхода к тестированию DDD-ядра привели к описанию Hexagonal Architecture (известной также под именем Ports And Adapters). Очень советую узнать подробности и поискать, как Вы могли бы сделать такое доступными Вам средствами PHP.

Пара других наводящих вопросов: должна ли работа с HTTP как-либо быть связана с взаимодействием с БД? Какой из компонентов системы должен знать параметры подключения к БД? Должны ли совпадать жизненные циклы ответа на HTTP-запрос и агрегатов в DDD-ядре? Должен ли HTTP-фреймворк диктовать Вам организацию DDD-ядра? Должен ли ORM-фреймворк диктовать Вам организацию DDD-ядра? А кто всё-таки должен?

Буду ждать Ваших комментариев.

Comments

[olijen]

Спасибо за ответ.

В моем приложении про подключение к бд знает компонент адаптера БД - надстройка над PDO, конфигурируется через ServiceLocator. Если Вы об этом, конечно. Но это часть фреймворка, я просто использую сконфигурированный компонент ORM на уровне инфраструктуры (в репозиториях, которые объединяют репозитории, как сервисы инфраструктурного слоя и коллекции по Эвансу - это моё компромиссное решение, позже разделю обязанности, возможно).

Про жизненный цикл не совсем понял. В php вообще с этим сложно. Технически, агрегат удаляется из памяти после каждого запроса, т.к. процесс убивается. А потом, со следующим запросом, я забираю данные из БД и собираю агрегат заново, десериализую его. Это сильно сбивает с толку. И сбивает с толку то, что я восстанавливаю только часть модели. К примеру, есть заказчик, есть проекты. Если я меняю его проект, я ведь не буду восстанавливать из базы всю коллекцию проектов, да и модель самого заказчика ресурсозатратно загружать. Получается как то странно. Может, лучше на сервере только REST сервер держать, а DDD на Angular2 на клиенте... Там ведь процесс в браузере дольше живёт и всё более "смоделированно" получится. Не знаю, понятно ли я объясняю суть.

HTTP не связан с взаимодействием с БД, как по мне, потому что сервис, на который попадает запрос, может запросить данные из файла, из не SQL хранилища или вообще с другого сервиса. У меня гибридный REST (гибридный, потому что у меня есть глаголы, а не только существительные, мне не понравилось помегательство на ресурсах, т.к. в итоге всё равно получается RPC через ресурсы).

Никто не должен диктовать организацию DDD ядра, кроме здравого смысла и логики. Ну, т.е. кроме самой предметной области, которая моделируется. Если в рабочих условиях - то здорово, когда есть доменный эксперт, который посодействует с тем, чтоб разобраться с предметами и связями. Но в моём случае я пишу своё приложение, которое автоматизирует работу аутсорс команды. Есть кастомер, у него проекты, у проектов задачи, у задач разработчики-исполнители и т.д. (Хотя, скорее не у задач разработчики, а у разработчиков задачи).

[Илья Толлю]

Употребляя слово "знает", я имею ввиду зависимости в коде. То есть, в php получается, что всё начинается с входящего http-запроса. Это означает, что где-то при обработке запроса задействуется ServiceLocator, который, вероятно, возвращает объект для работы с БД. Получается, что обработчик http-запроса "знает" о существовании БД. Он же, вероятно, создаёт экземпляр модели и передаёт кому-то свои "знания" о БД, чтобы с моделью можно было что-то сделать.

Вот и получается, что первую скрипку играет обработчик http-запроса, который по совместительству является точкой входа в приложение. А все остальные адаптируются под этот обработчик. Или фреймворк. Что противоречит логике и смыслу DDD.

Теперь про часть модели. Не помню точно источник цитаты, но где-то приведены слова Эрика Эванса о том, что если бы он писал эту голубую книгу сейчас, то начал бы с Ограниченных контекстов. Потому что именно это является самым важным в DDD: разбиение задачи на набор ограниченных контекстов, которые находятся между собой в определённых отношениях. И он описал виды этих отношений. Кроме этого, внутри самих контекстов разбиение на агрегаты устанавливает границы транзакций. Об этом достаточно подробно писал Vaughn Vernon в книге Implementing Domain-Driven Design.

С REST проблема в том, что в данном случае предметная область не вписывается в ресурсную модель. Ведь именно поэтому мы и используем DDD. Наверно, из фронтэнда формируются запросы к агрегатам. Но агрегаты в объектном виде не являются ресурсами. Они сами по себе обладают сложной внутренней логикой. Если переносить эту логику на фронтэнд, то мы получим толстого клиента, двухзвенную архитектуру. Если с таким подходом всё сработает - отлично, используйте Firebase. Но с DDD нужно поступать иначе. И ресурсная модель тут оказывается очень полезной.

Я предлагаю применить CQRS - Command-Query Responsibility Segregation. При таком подходе фронтэнд либо направляет агрегатам команды, которые и являются ресурсами, либо запрашивает представление некоторой модели для чтения.

Вот какие у нас образуются компоненты и роли:

• Команда - ресурс, иммутабельная структура данных, содержащая всё необходимое для того, чтобы агрегат мог решить, что с ней нужно сделать.
  
• Агрегат - хранит состояние части предметной области; принимает команды, в результате чего может изменить состояние; при изменении состояния издаёт оповещение, которое могут использовать другие компоненты.
  
• Контроллер модели для чтения - подписывается на оповещения от интересующих его типов агрегатов (возможно, в разных контекстах) и формирует (или обновляет) денормализованную модель для чтения, которую складывает в key-value или документную db (или в blob, на худой конец); при обновлении модели издаёт оповещение для заинтересованных компонентов.
  
• Модель для чтения - ресурс, документ; как правило JSON,
  запрашиваемый фронтэндом.
  
• Запрос к контроллеру коллекций - ресурс, иммутабельная структура данных, предусматривающая каноникализацию и вычисление хеша; описывает параметры поиска, фильтрации и сортировки определённой коллекции.
  
• Контроллер коллекций - принимает запросы к коллекции (аналогично тому, как агрегаты принимают команды), реализует логику поиска, фильтрации и сортировки моделей для чтения; в результате работы создаёт новую модель для чтения - коллекцию.
  
• Коллекция - ресурс, поддерживающий постраничное листание. Задача коллекции - дать краткое описание и гиперссылки на модели для чтения входящих в неё элементов
  

Ресурсы, как правило, представлены иммутабельными структурами данных и содержат логику максимум для авторизации.

Основная логика сосредоточена в агрегатах (DDD, модель предметной области), контроллерах моделей для чтения (они знают, как из разных объектов предметной области сформировать нужные документы) и контроллерах коллекций (они знают, как искать, фильтровать, сортировать модели для чтения).

Также несложно добавить сюда Event Sourcing там, где он нужен. Для этого достаточно состояние агрегатов хранить в БД в виде последовательности событий, описывающих изменение их состояния. Тогда контроллеры моделей для чтения должны уметь делать foldLeft этих последовательностей. Очень удобно в том случае, если необходимо хранить не только текущее состояние модели предметной области, но и историю изменений.

Фронтэнд теперь может спокойно работать в REST-стиле. На бэкэнде дополнительно потребуется логика для формирования гиперссылок. Получается так:
1. Фронтэнд формирует запрос к контроллеру коллекции, выполняет POST.
2. Контроллер коллекции собирает коллекцию, отвечает Created с гиперссылкой на коллекцию.
3. Фронтэнд идёт по этой ссылке к ресурсу коллекции (GET), получает от ресурса коллекции первую страницу и вместе с ней ссылки на другие страницы.
4. По ссылке из коллекции запрашивает (GET) модель для чтения, в которой есть ссылки на необходимые агрегаты.
5. Фронтэнд формирует команду и обращается с ней к нужному агрегату (POST), получает в ответ Created и ссылку на созданную команду. Идёт по ссылке и получает описание команды вместе со ссылками на модели для чтения, которые были созданы или обновлены в результате выполнения команды (или сообщение об ошибке).
6. Фронтэнд запрашивает (GET) нужную модель для чтения и показывает её пользователю.

Конечно, пользователь может добираться до агрегата и не через коллекцию, просто это достаточно распространённый юз-кейс.

Вот такой получается REST и DDD. Конечно, это всего лишь один из возможных вариантов. При конкретной реализации могут возникнуть дополнительные нюансы и детали. На мой взгляд, этот вариант может оказаться достаточно интересным.

По моему собственному опыту могу сказать, что очень удобно (даже ОЧЕНЬ удобно) моделировать серверную логику с помощью модели акторов. В PHP такой, по-моему, нету. Модель акторов реализована нативно в Erlang/Elixir, а также в виде библиотек на .Net, JVM и других языках и платформах. С её помощью получается физически разделить http-сервер, адаптеры к хранилищам данных, бизнес-компоненты. Тогда они живут со своими собственными жизненными циклами и обмениваются друг с другом асинхронными сообщениями. Например, представление агрегата может жить в памяти сколько-то секунд после выполнения команды. Тогда, если следующая команда укладывается в отведённый таймаут, агрегат не нужно будет заново вытаскивать из хранилища. Кроме того, у агрегатов, контроллеров моделей для чтения и контроллеров коллекций жизненные циклы не совпадают.

Но модель акторов - это уже совсем другая история, сильно выходящая за рамки исходного вопроса.

[olijen]

Большое спасибо за развёрнутые ответы, это ценная информация.

(дальше целый абзац, который не по делу и его можно не читать)
Но для меня всё это будет, пожалуй, оверхед, т.к. у меня цель не только разобраться в DDD и LayerArchitect, но еще и практиковать кучу различных технологий от начиная с OS (bash, linux, администрирование, конфигурирование, виртуализация и provision), продолжая сервером бекенд, на котором Yii2 с уже переписанным каркасом под слои и инфраструктурой для удобного баг-фикса и вообще для удобного развёртывания и разработки проекта (в связке с MySQL и MongoDB, если успею), фронтендом с Angular2 и TypeScrypt, который я не использовал никогда, но написал уже некоторую часть приложения (кстати, интересно). В придачу к этому еще всякие не технические штуки типа продаж, руководства новосозданной командой, тайм-менеджмента, таск-менеджмента, ведения базы знаний, документации, распределения обязанностей. Казалось бы - максималистическая чушь, многие считают, что нужно заниматься одним и не лезть куда попало. Но я спецом уволился с последней должности, чтоб наладить вот такое вот хобби. Так что этот вопрос - это только часть моих увлечений.

Но всё таки касательно менее наполеоновских планов, чем Вы описали (я банально не успею разобраться с CQRS и ES, уже читал об этом, хотя это очень интересно). Можете прокомментировать мою задумку на приложение?

Само приложение - это автоматизация процесса оказания услуг. К нам обращается клиент, у него есть проект (зачастую это не идея - а существующий проект), он может создавать задачи по проекту, обсуждать с инженерами. Инженеры могут запрашивать некоторые шаблоны на заполнение - типа FTP, admin-panel, hosting-panel и т.д.
Мои "сотрудники" (бывшие "ученики") занимаются обслуживанием проектов на WordPress и мелким ремонтом\оптимизацией - то, что никто делать не хочет на рынке, ибо сильно "крутые".

На фронтенде пока не совсем понятно, что будет, т.к. у меня нет хорошего опыта Angular2 & TypeScript. Много вопросов, пока не могу определиться с зоной ответственности фронтенда, но я работаю над этим. Пока он просто работает по простому CRUD-REST, но я уже предусмотрел, что REST нужно будет сделать гибридным, чтобы передавать действия, иначе будет оверхедное злоупотребление идеи ресурсов. Кстати, конечно же SPA совсем тут не обязательно - это я уже для прокачки опыта усложнил, интересна технология TS.

Бекенд принимает REST запрос (иногда это может быть действие, к примеру "начать обсуждение проекта" - что в итоге меняет в объекте статус). Есть слой контроллеров и действий. Класс контроллера отвечает за авторизацию на действие, разрешает cors, перенаправляет на action. Класс action - это как бы сервис слоя Presentation. Он просто принимает запрос, передаёт данные в сервис приложения, максимум - делает очень простые проверки, ставит HTTP статус и возвращает данные, которые уже фреймворком преобразуются в JSON и уходят на клиент.

Сервис слоя приложения является моделью бизнес-процесса (?) и является самой толстой частью. Он может вызывать несколько действий (к примеру, создать объект, записать в логи), что позже будет переписано, например, в декораторы, но это позже. В простом случае, сервис может взаимодействовать либо напрямую с бизнес-объектом, либо запрашивать его через хранилище (репозиторий). Например, может создать бизнес-объект, записать в него данные, которые пришли с клиента, а потом через репозиторий и метод save сохранить его в базу.

Репозиторий как сервис уровня инфраструктуры. У меня он, пожалуй, не каноничный. Он является моделью хранилища. Умеет сохранить чистый бизнес-объект в базу (без ActiveRecord, только DAO и QueryBuilder), умеет по запросу типа fetch вернуть бизнес объект. Внутри имеет всякие вспомогательные конвертеры, которые позволяют воссоздать запрошенный бизнес-объект по данным из БД (вот сейчас понял, что не надо заново создавать, это ошибка. Нужно десериализовать по данным). Является адаптером между "чистыми" бизнес объектами и их способом хранения.

Ну и сам слой бизнес модели - сущности и объекты-значения, агрегаты. Пытаюсь сделать модели Rich, а не Anemic, но не уверен, что всё правильно понимаю. Anemic - это понятно. А Rich - если я правильно понимаю, это добавляет методы поведения. Т.е. объекты могут менять свои свойства, избавляя от этого слой приложения, который просто может вызвать метод, в зависимости от action. Но тут ен понятно, как распределить обязанности между моделями, чтоб не нарушать SRP. Какой объект чьи состояния может менять? Какие методы должны быть у модели? Не очевидно, хоть с логикой дружу немного.
Для меня шло в разрез логике, к примеру, что сущность "задание" может иметь метод "startConversation()", который меняет её статус и задание становится в состоянии "переговоры". Ведь вещи не могут менять своё состояние... Это делает объект, наделённый волей... И пошел-поехал загоняться в философию. У меня получилось, что никто, кроме наследников класса Human не может ничего менять. Позже я понял, что это пустая трата времени и надо немного иначе смотреть на модель. Остановился на том, что объект может менять своё состояние и состояние "подчинённых" объектов. Хотя масса вопросов (и подавленной агрессии) осталось. Если подбросите идею, как сделать красивую и логичную модель для перфекциониста в условиях умирающих запросов - буду признателен.

Конечно, появятся еще интерфейсы, но т.к. пока всё очень динамично, я подгоню интерфейсы, когда определюсь с деталями реализации, хоть надо и наоборот.

Как то так. Сейчас нет намерения пытаться прыгнуть в космос и сделать всё совсем идеально, но хочу сделать заготовку хорошей архитектуры с грамотно распределенными обязанностями/ответственностями. Золотую середину нащупать, чтоб без оверхедов, но и без transaction-script-ов и нарушения SOLID. Может я много хочу просто... =))

[Илья Толлю]

На мой взгляд, идея любого ИТ-решения, которое может каким-то образом улучшить существовавшие до него процессы или создать что-то новое и ценное - уже достаточно хороша, чтобы её воплощать, когда к этому есть интерес. Разумеется, тут нужно сопоставлять идею и ценность, которая может быть привнесена.

У фронтэнда роль достаточно важная. Если бэк реализует логику предметной области, занимается масштабированием, отказоустойчивостью и всё такое, то фронт обеспечивает непосредственное взаимодействие с пользователем. Логика навигации, логика уведомлений, логика работы с таблицами и формами, всякие master-detail-ы, графические визуализации, оповещения - это всё фронт. Обеспечение визуальной связанности представлений там, где она есть логически, избавление пользователя от лишних действий, создание ощущения "отзывчивости" приложения...

Хобби заслуживает исключительного уважения. Относительно идеи бизнеса изложу свой взгляд. У IT-бизнеса есть редкое качество: он потенциально масштабируем. Это означает, что существуют такие бизнес-идеи, которые при малых затратах человекочасов способны найти миллионы потребителей. Именно такие идеи интересны в первую очередь. Я здесь имею ввиду продуктовую модель. Понятно, что если мы работаем на заказ - то решаем именно эту самую заказанную задачу. Но продукт ориентируется на большое количество потребителей. Собственно, у IT есть два способа заработать много денег: или очень крупный проект, или очень масштабный продукт. Первое - это очень специфическая ниша, в которую кто попало не имеет доступа. Второе - сфера деятельности стартапов. Рискованно, но реально и интересно. Хорошо, не будем говорить "заработать много денег". Скажем политкорректнее: "возыметь большое влияние и резонанс".

Ещё одно преимущество продуктового подхода перед проектным заключается в том, что все члены продуктовой команды могут иметь гораздо лучшее и более перспективное видение продукта - соответственно, лучшую мотивированность и креативность. Это непосредственно сказывается на работоспособности людей и качестве результата.

И, наконец, на мой взгляд, каждый IT-лидер (включая тим-лида и архитектора) несёт ответственность за то, чтобы люди, выполняя работу ощущали свой рост. Чем больше человек делает, тем больше он должен познавать. Он должен чувствовать, что начинает лучше представлять себе цель, процессы, инфраструктуру, совершенствуется. Иначе говоря, IT-лидер должен сделать так, чтобы люди работали не только за деньги и бонусы, но и из-за интереса к самой работе. Потому что именно это может оправдать расход самого ценного и невосполнимого ресурса у каждого человека - минут и часов его жизни. Опять же, это очень сильно влияет на скорость работы и качество результата.

Возможно, мои слова как раз выражают позицию по крайней мере части тех, кто не хочет тратить время на мелкий ремонт и оптимизацию чужого говнокода. Не потому, что "крутые", а потому, что время невосполнимо. Приобретя в этом некоторый опыт, я начал считать такую работу в высшей мере неблагодарной. Как правило, заказчиками таких работ являются владельцы бюджетных интернет-магазинов, не обладающие видением своего произведения, не представляющие себе своих потребителей и не стремящиеся сделать хороший бизнес. А просто надеющиеся найти сравнительно нетрудоёмкий источник дополнительного дохода. Для таких мне не хочется ничего делать ни за бесплатно, ни за деньги. Разумеется, и из этого правила есть исключения.

А с архитектурой нужно экспериментировать. Каждый новый проект будет приносить открытия, если их искать. Если есть стремление делать чистую и простую архитектуру - то постепенно это будет получаться. Заготовку хорошей архитектуры сделать едва ли получится (как и заготовку хорошего дворца, в случае с архитектурой зданий) - это скорее возможность понять, как все изученные понятия вместе работают. Понять, между чем и чем делается выбор; что приносится в жертву, а что выигрывается.

Вот, кстати, насчёт анемичных моделей мне не совсем понятно. То есть, понятно, что это не ООП-шно. Ну а если я использую не [только] ООП, а функциональный подход? Например, замечательные модели можно строить на F#, на Scala, на Elixir. В последнем случае об объектах вообще не идёт речи: у нас есть именно что структуры данных и функции над ними. А функции открывают массу возможностей, включая функциональную композицию, простоту тестирования, отладки и спецификации. В общем, для меня достоинства богатых доменных моделей являются очень неочевидными. Так что, советую более функциональный подход. Некая структура данных моделирует состояние некоторой сущности. Над этим состоянием можно произвести какое-то чисто логическое действие (функцию без побочных эффектов) и получить новое состояние. С этим новым состоянием можно сделать что угодно: передать кому-то, сохранить в БД, залогировать... И этот вовсе не процедурное программирование с так нелюбимыми Мартином Фаулером транзакционными скриптами. Нет, это отделение чистой логики от эффектов - следующий уровень реализации Single Responsibility Principle. Есть хорошая книжка: Functional And Reactive Domain Modelling. Правда, она достаточно серьёзно опирается на Scala, это проблема. Но какие-то общие принципы вполне можно оттуда почерпнуть. Совсем недавно вышла также книжка, где за основу взяты Elixir и Phoenix: Functional Web Development with Elixir, OTP, and P.... Насчёт PHP не знаю. Возможно, стоит поискать - тема очень уж хороша. Ещё, думаю, отдельную книжку стоило бы посвятить Гексагональной архитектуре (она идеально сочетается с DDD), но такой пока никто не написал.

А что Вы имеете ввиду под условиями умирающих запросов?

Золотая середина - это очень ускользающая концепция. Если масштаб системы известен заранее - то выбор будет между решением, достаточным для бизнеса и решением, несущим новый опыт в рамках отведённого времени на него. Если масштаб меняется со временем - будет меняться и золотая середина. Если сложность системы, развитость кода меняется - это тоже окажет своё влияние. Или если меняется доступное для обучения время. Но зато можно каждый раз делать выбор с открытыми глазами.