Как связать 2 сущности?

Question

[Михаил]

Решил разобраться в DDD и встал перед проблемой формирования сущностей. В данный момент в проекте есть 2 источника: собственная база и API. Частично сущности пересекаются и можно сделать код который будет работать с 2 системами, но есть исключения. Например, в обоих системах есть пользователи разных типов которые ничего не знают друг о друге и требуют манипуляцию с каждым отдельно. Не понятно как в таких случаях применять DDD.

Есть ли примеры таких решений?

Answer 1

[Максим]

PS: Я не хочу как-то закидать Yii какахами, поэтому подчеркиваю - нужно выбирать инструмент реализации исходя из потребностей.

Вы не сможете полноценно применять DDD в Yii. Потому что Yii не способен на это =) (способен, но нужно допиливать).

Суть DDD в выделении предметной области и ее независимости от реализации и инфраструктуры. То есть предметная область, ваша логика, должна быть написана чуть ли не на голых объектах. То есть она вообще независима, вы можете взять написать тест на объект предметной области и он будет работать без фреймворка.

При использовании DDD вам просто необходимы конструкторы, объект не может быть создан если не указаны все его параметры. И за это должен отвечать не какой-то там валидатор или база или сеттеры, за это должен отвечать конструктор!

Объект предметной области не может маппиться на базу внутри этого объекта - это уже часть реализации. Это нарушает букву S в такой штуке как SOLID =)

В Yii по факту не получится разбить приложение на слои Domain layer, Persistance Layer, Application (Service) Layer, View Layer. Из за модульной архитектуры. Можно допилить, но зачем?

Нужно отказываться от Active Record полностью, ставить доктрину или писать свои мапперы в Persistance Layer, что геморойно.

Ну и вывод:
Вообще Yii сам по себе очень простой фреймворк для простых задач, для прототипирования, для приложений с коротким циклом поддержки, в котором использование ERP практик из коробки невозможно. При этом я не отрицаю, что на нем можно написать большое приложение и может быть (здесь я не уверен), вы сможете его поддерживать долгое время. Сильная связанность всех компонентов, ActiveRecord, убогий DI контейнер (может что-то поменялось, но в 1ых версиях Yii2 он был реально убогий) и тдтп. Почитайте про объектно-ориентированный дизайн, про SOLID, вникните и еще раз взгляните на свой код на Yii. И если вам реально необходим DDD, посмотрите на более подходящие решения - Symfony, Zend.

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

Comments

[Михаил]

Спасибо за крутой ответ!

На счет 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 одинаковыми предметными областями - не понятно. В моем вопросе пример про пользователей.

[Никита]

Очень много написали, а по факту - либо вы не знаете о чем пишите, либо просто захотелось написать ерунду.
Особенно это:
>"В Yii по факту не получится разбить приложение на слои Domain layer, Persistance Layer, Application (Service) Layer, View Layer. Из за модульной архитектуры. "
Непонятно при чём здесь подход к созданию приложения и фрейморк. Как хотите писать приложение - так и пишите, фреймворк(любой) никак не может помешать - он лишь помогает."Из за модульной архитектуры" - ??? О чем вы? При чем здесь промежуточные слои модели со сторонними компонентами и модульность?
Писать приложение, используя Yii, не подразумевает разбиение приложения на выше перечисленные слои, хотя многое без труда реализуется, но это и не нужно в большинстве случаев, так как абстракций предлагаемых Yii вполне достаточно.

>"Сильная связанность всех компонентов, ActiveRecord, убогий DI контейнер"
Шикарная реализация ActiveRecord; DI удобный и надо уметь готовить, но это субъективно; Сильная связанность всех компонентов - единственная проблема, которая заслуживает внимания в отрицательном смысле и она (проблема) уже на стадии решения (вроде бы).

[Максим]

Никита: промежуточные слои модели? Это что такое? Я думал мы говорим о hexagonal architecture, а не о "промежуточных слоях модели" :) Погуглите и попробуйте написать что-то более сложное чем MySQL + CRUD. Например, бухгалтерию :)

[Максим]

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

[Максим]

Никита: и я не говорил, что реализация актив рекорд убогая. Сам по себе паттерн актив рекорд убогий, потому что он объединяет в себе бизнес логику и работу с базой. Value Object сразу в топку, независимость предметного объекта от базы в топку. Это ж не важно, но только если у вас маленькое приложение.
Извиняюсь за то что 3 сообщения. С телефона пишу :)

[Андрей]

Максим: Я конечно может многого не понимаю, но кто вас заставляет использовать Active record? Можно просто использовать базовую модель, либо вообще свой кастомный php класс, а данные маппить на тот же эктив рекорд, либо на что нибудь уровнем пониже QueryBuilder, либо вообще \yii\db\Query напрямую запросы выполнять и использовать все свои ddd приблуды.

[Никита]

Максим: писал я бухгалтерию, дело в том, что в Yii модели (Model класс) охватывают очень много функционала и поэтому из слоя "модель" можно сделать 3 других лишь создав соответствующие папки. Ну и не обязательно наследовать свои классы от модели, во многих случаях достаточно писать голые классы (например сервисы). А если эти голые классы наследуются от yii Object, то они становятся легко используемые в контексте Yii приложения.

[Максим]

Никита: Андрей: Я не буду спорить, можно сделать все, но для этого нужно перелопатить пол фреймворка, можно использовать QueryBuilder, можно написать свой UnitOfWork. Но все это уже написано за нас и все это легче использовать с Zend и Symfony, чем интегрировать в Yii, а нужна именно интеграция из-за сильной связанности внутри фреймворка.
Yii модели охватывают много функционала - так это недостаток больше, чем преимущество. Класс должен иметь единую ответственность, а не уметь все. Но в действительности - это проблема ActiveRecord в общем.
Насчет контекста Yii. Зачем мне привязывать мою предметную область к конкретному фреймворку? Наследоваться от чего-то. Зачем? Я пишу в своих проектах предметную область на голых объектах. Закрываю репозитории интерфейсами, пишу сервисы с использованием этих репозиториев и интерфейсов нужных мне либ. Далее покрываю все это тестами мокая репозитории и эти сервисы. До этого шага у меня вообще нет никаких фреймворков, нет вообще ничего. Есть только моя бизнес задача. Которую я могу оттестировать еще до интеграции и реализации. Далее подрубаю доктрину, external mapping'ом маплю объекты на базу\кеш (при этом структура базы может быть абсолютно любой, она не привязана к моей предметной области, потому что объект не является таблицей\документом БД). Реализую репозитории, сервисы, логику самого Application Layer. И потом на это делаю сколько угодно интерфейсов (console, web, api).

И еще раз повторю, что под каждую задачу свои инструменты. Если вам хватает Yii и его идеологии, то это не значит, что всем ее хватает и всех она устраивает. Человек изучает DDD, а Yii для этого совсем не подходит, потому что DDD - это ERP паттерн, а Yii не ERP фреймворк.

Михаил: А вот для вас хорошее видео для понимания слоев свойственным DDD, начиная от Anemic Model до CQRS: https://www.youtube.com/watch?v=ajhqScWECMo

[Андрей]

Максим: про Service, Repository, Application layer читал, занятно, теперь стало интересно какие асбтракции может предложить сам Symfony есть почти все руками собирается, но это уже тем не этого топика)

[Михаил]

Все очень много расписали, а по факту как быть с 2 сущностями никто не овтетил.

[Максим]

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

[Максим Тимофеев]

Михаил: "Все очень много расписали, а по факту как быть с 2 сущностями никто не овтетил."
если максимально упростить, то у Вас есть model User, которую наследуют модели User1 и User2.

[Максим]

Максим Тимофеев: Почитайте про вот этот принцип, очень пригодится чтобы избавиться от такого наследования: https://en.wikipedia.org/wiki/Liskov_substitution_...

[Михаил]

Максим: я в комментарии дополнил и вроде информации должно хватать.
Есть User model для работы с 1 категорией пользователей (текущая система).
Есть User model для работы с 2 категорией пользователей (другая система).

Вопросы:
1) Юзеры, к примеру, объединить нельзя, работа ведется по отдельности.
Так и называть сущности UserSystem1Model, UserSystem2Model?

2) Товары, к примеру, объединить надо, но только частично.
Как в данном случае выделить сущность не понятно. Чтобы было ясна ситуация, предлагаю посмотреть на демонстрацию inner join (не в sql-контексте).

p.s. картинка https://www.google.com/search?q=mysql+join&newwind...

[Михаил]

Максим: кстати, получается совет от yii2 использовать базовую модель в common и наследование от нее в других модулях является анти-паттерном?

[Максим]

Михаил: Наследоваться можно только в том случае, когда замена наследника на родителя и наоборот не влияет на последующий код программы и соответственно не ломает логику работы. Дефолтный пример с прямоугольником и квадратом легко гуглится по Liskov Substitution example.
Но Yii имеет другую идеологию и применение SOLID и таких практик как DDD в нем затруднено.
Вам нужно выносить обработку пользователей в два разных класса или набора классов и с помощью фабричного метода или фабрики соответственно создавать обработчики.
Примитивный пример сделал вот здесь: sandbox.onlinephpfunctions.com/code/7ce605472b9755...
Обратите внимание, что реализация user тут абсолютна не важна в самом коде программы, она важна только для конкретного обработчика. А обработчик приводит работу с обеими пользователями к единому виду.
Надеюсь я правильно понял задачу, которая стоит перед вами.

[Михаил]

Максим: я понял идею, только оптимизма это не добавило :) Сложно было бы реализовать такую систему.

Не хочу плодить вопросы, как в контексте DDD реализовать API? Я имею ввиду что при обычной работе с базами есть сущности которыми просто манипулировать, а API в основном отдает некую связку сущностей, получается, нужно разбивать ответ?

[Максим]

Михаил: В DDD не важно откуда берутся сущности, потому что это просто сущности. И классы которые их достают в domain слое есть только в виде интерфейса. По сути это репозиторий. Только он работает не с базой, а с API. Для того чтобы понять полностью как это работает, нужно понять как отвязывать предметную область от реализации.

[Михаил]

Максим: да, это понятно, хорошим примером стал https://github.com/brianium/tdd-ddd-php

Не понятно как разложить многоуровневую структуру на разные сущности (в каком слое?).

[Максим]

Михаил: Я не понимаю проблемы, несколько уровней никак не коррелируют с количеством сущностей. Отвяжитесь от базы сначала, от API, вообще полностью от реализации. Подумайте какие действия выполняют у вас оба вида пользователей. Если они идентичны то и в предметной области у Вас один пользователь, а откуда берутся данные и как они обрабатываются вы уже решаете в инфраструктуре - то есть в реализации. Например вы делаете два репозитория DbUserRepo и ApiUserRepo, и в нем занимаетесь преобразованием. Оба репозитория вернут вам сущность пользователя. Если вам далее нужны разветвления то это уже задача обработчиков, вы проставляете пользователю источник, чтобы приложение знало как с ним работать. Например записываете при получении пользователя по API какой-нибудь type:api, а при получении из базы type:db. Далее по этому типу создаете обработчик, у которого есть например метод send, один отправляет пользователя в базу, другой через API.

[Михаил]

Максим: Должны ли в сущность пользователей входить их адреса? Если нет, то значит ли это что при необходимости получить адреса юзера нужно запрашивать [GET] system/api/v1/user/id, выбирать ->addresses и инициализировать репозиторий?

[Максим]

Михаил: Должны, если в идеале как ValueObject и должны поддерживать eager и lazy loading. В таких штуках как Doctrine для класса предметной области создается Proxy, который перехватывает запрос (при lazy loading) к $user->addreses и направляет его в базу(или в другое место, это решает репозиторий) для последующей гидрации. Я бы 10 раз подумал перед тем как решить все это писать самому в YII. ActiveRecord в этом плане работает со связями по другому. Вы можете посмотреть какие методы используются для вытягивания моделей и подменить их, но я думаю что вы столкнетесь с невероятным количеством проблем. Проще будет вытягивать их из API по потребности(может быть даже по крону) и преобразовывать в Yiiшные модели. ActiveRecord сильно связывает вам руки в этом плане и загрязняет код.

[Михаил]

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

Проблема таких сильных абстракций в затраченном времени, к сожалению, оно не всегда есть.