Статья о проекте на PHP. То что я говорил касается PHP. Тут все прекрасно делается моками.
С третьей, сама база, схемы конкретных таблиц могут быть частью интерфейса.
Чисто теоретически. Я думаю, что в описываемом проекте такого нет. Да и вообще, я глубоко сомневаюсь, что кто-то реально будет делать БД частью интерфейса ограниченного контекста.
В целом одна база никак не противоречит разделению на контексты.
По мне так база это часть релизации контекста, сугубо внутренняя вещь. Чтение напрямую из базы минуя интерфейсы контекста приводит к нарушению принципа сокрытия информации на уровне контекстов.
Уже есть такие примеры, что, переделывая какой-то кусочек, его стараются упорядочить и интерфейсами покрыть, чтобы оно было более-менее похоже на чистую архитектуру, чтобы было проще потом вынести.
Просто интерфейсами покрыть, чтобы было похоже на «чистую архитектуру»? По-моему опыту так делать не надо, все закончится созданием кучи никому не нужных интерфейсов и только добавит акцидентальной сложности. По-моему в прикладном проекте (не в библиотеке) интерфейсы нужно делать только тогда, когда на 100% знаешь, что будет больше одной реализации. YAGNI. А так ощущение создается, что в описываемом проекте люди только открыли для себя интерфейсы и DDD и пустились применять просто потому что это «круто». Ничего, время все расставит на свои места, набьются шишки. Лучше конечно их набивать используя прототипные проекты а не основной.
Мы решили скрестить ужа с ежом и теперь живем с двумя фреймворками.
Сейчас хитрим и читаем из чужих таблиц — это допущение, которое мы пока себе позволяем в силу того, что нет времени, ресурсов, чтобы реализовать по-нормальному. Когда есть такой сложный кейс — иногда мы отходим от правил и читаем прямо из базы данных.
Сейчас в новом коде у нас 14-15 контекстов плюс большой легаси
По-моему в проекте проблем стало еще больше. О каком разделении на контексты можно говорить, если база одна?
Интересно, решили ли они делать persistence ignorance?
Я уже объяснил свою позицию в другой ветке. Повторюсь. Если бизнес-логику в сущности помещать, то она станет перегруженной рано или поздно, с ростом количества кейсов использования сущности и, соответственно, ростом количества бизнес-методов сущности. С сервисной декомпозицией такого не произойдет. У сущности одно дело в приложении — представлять бизнес данные, и хватит с нее. Инварианты держать — это задача всего домена, не только сущностей и агрегатов.
Анемичные модели, dto vs entity это проблемы не java, а в целом ООП подхода
Это не проблема ООП подхода. Это проблема программистов, его использующих, недостатка их олыта.
Логика в моделях в первую очередь должна быть связана непосредственно с данными модели, как-то – валидация данных, констрейнты. Там где логика завязана на несколько моделей, в дело вступают сервисы.
В целом согласен, но еще бы учтонил, что бизнес-методы не должны быть в сущностях и агрегатах, они должны быть в сервисах. Сущности это слой данных по сути своей и их задача представить данные в приложении (оффтоп: поэтому DataMapper необязателен, с таким подходом можно и dao и row gateway использовать, все хорошо будет).
ООП работает и нужно. Объясняется количеством ПО с его использованием. Конечно, можно заниматься поиском определений и лучших подходов, но это удел академического сообщества. Я, как практикующий программист, не представляю сегоднящнюю разработку без ООП
У сервисов состояние так или иначе есть. Это зависимости: другие сервисы, конфигурация приложения, шлюзы к БД, шлюзы к API, диспетчеры событий и пр. И всё эти зависимости можно мокать и сервис хорошо тестируемый и реюзабельный. Ответил на ваш вопрос зачем ООП язык?
Отделять их затем, что если бизнес-логику в сущности помещать, то она станет перегруженной рано или поздно, с ростом количества кейсов использования сущности и, соответственно, ростом количества бизнес-методов сущности. С сервисной декомпозицией такого не произойдет. У сущности одно дело в приложении — представлять бизнес данные, и хватит с нее.
Я тоже раньше придерживался такого же мнения про rich-модели, потом пришел к тому, что сущности это все таки слой данных. Бизнес-логику предпочитаю в бизнес-сервисах далать.Сложность и дублирование купировать при помощи декомпозиции сервисов.
Все таки это отличается от процедурного кода, так как сервисы не используют глобальное состояние, их можно тестировать изолированно. А разделение на сущности и сервисы никуда не денешь, так как это природа вещей, сама предметная область подразуевает наличие данных.
когда можно обойтись одним — полноценной работой сущности.
Не получится одним обойтись. Либо зависимости понадобятся для бизнес-логики, которые сущность сделают сильно связанной, либо найдется поведение, которое в рамки одного агрегата не влезет. Не панацея.
Не думал об этом)
Я имел ввиду что о PHP говорено переговорено, на Reddit, на Quora, вроде выяснили что PHP нужен, а здесь снова старая песня о главном)
идея о том, что можно сделать абстрактную модель, а потом отобразить ее на имеющуюся инфраструктуру очень наивна. Кто сказал, что это вообще возможно эффективно сделать?
Да доказательств никаких не было и нет. Просто кому-то когда-то это показалось возможным и пошло поехало…
По мне так верно обратное. Инфраструктура в основном тон проекту задает, особенно нагруженному. Разработчики получают деньги как раз за «укрощение инфраструктуры». В последнее время пришел к выводу, что более эффективными являются абстракции построенные «снизу» от инфраструктуры, а не сверху по описанию предметной области.
Да. Я его тут привел затем, что для приложения на PHP Centrifugo будет как внешний сервис, доступный через HTTP API. Погружение в go будет совершенно ненужно для решения поставленной задачи (создания чатика). Достаточно умения развернуть Centrifugo и сделать к нему запросы. Centrifugo поможет с удержанием постоянных соединений до клиента.
У вас чувство юмора такое? Вы же с первого раза поняли, какие моки имеются ввиду. Все что вы написали я прекрасно знаю, зачем вы всё это перечислили?
События можно версионировать. Со схемой базы это не получится.
Статья о проекте на PHP. То что я говорил касается PHP. Тут все прекрасно делается моками.
Чисто теоретически. Я думаю, что в описываемом проекте такого нет. Да и вообще, я глубоко сомневаюсь, что кто-то реально будет делать БД частью интерфейса ограниченного контекста.
Нет
По мне так база это часть релизации контекста, сугубо внутренняя вещь. Чтение напрямую из базы минуя интерфейсы контекста приводит к нарушению принципа сокрытия информации на уровне контекстов.
Просто интерфейсами покрыть, чтобы было похоже на «чистую архитектуру»? По-моему опыту так делать не надо, все закончится созданием кучи никому не нужных интерфейсов и только добавит акцидентальной сложности. По-моему в прикладном проекте (не в библиотеке) интерфейсы нужно делать только тогда, когда на 100% знаешь, что будет больше одной реализации. YAGNI. А так ощущение создается, что в описываемом проекте люди только открыли для себя интерфейсы и DDD и пустились применять просто потому что это «круто». Ничего, время все расставит на свои места, набьются шишки. Лучше конечно их набивать используя прототипные проекты а не основной.
По-моему в проекте проблем стало еще больше. О каком разделении на контексты можно говорить, если база одна?
Интересно, решили ли они делать persistence ignorance?
Я уже объяснил свою позицию в другой ветке. Повторюсь. Если бизнес-логику в сущности помещать, то она станет перегруженной рано или поздно, с ростом количества кейсов использования сущности и, соответственно, ростом количества бизнес-методов сущности. С сервисной декомпозицией такого не произойдет. У сущности одно дело в приложении — представлять бизнес данные, и хватит с нее. Инварианты держать — это задача всего домена, не только сущностей и агрегатов.
Это не проблема ООП подхода. Это проблема программистов, его использующих, недостатка их олыта.
В целом согласен, но еще бы учтонил, что бизнес-методы не должны быть в сущностях и агрегатах, они должны быть в сервисах. Сущности это слой данных по сути своей и их задача представить данные в приложении (оффтоп: поэтому DataMapper необязателен, с таким подходом можно и dao и row gateway использовать, все хорошо будет).
Отделять их затем, что если бизнес-логику в сущности помещать, то она станет перегруженной рано или поздно, с ростом количества кейсов использования сущности и, соответственно, ростом количества бизнес-методов сущности. С сервисной декомпозицией такого не произойдет. У сущности одно дело в приложении — представлять бизнес данные, и хватит с нее.
Все таки это отличается от процедурного кода, так как сервисы не используют глобальное состояние, их можно тестировать изолированно. А разделение на сущности и сервисы никуда не денешь, так как это природа вещей, сама предметная область подразуевает наличие данных.
Не получится одним обойтись. Либо зависимости понадобятся для бизнес-логики, которые сущность сделают сильно связанной, либо найдется поведение, которое в рамки одного агрегата не влезет. Не панацея.
Хороший стэк и работать удобно, когда есть PHPStorm + Symfony Plugin
Не думал об этом)
Я имел ввиду что о PHP говорено переговорено, на Reddit, на Quora, вроде выяснили что PHP нужен, а здесь снова старая песня о главном)
Да доказательств никаких не было и нет. Просто кому-то когда-то это показалось возможным и пошло поехало…
По мне так верно обратное. Инфраструктура в основном тон проекту задает, особенно нагруженному. Разработчики получают деньги как раз за «укрощение инфраструктуры». В последнее время пришел к выводу, что более эффективными являются абстракции построенные «снизу» от инфраструктуры, а не сверху по описанию предметной области.
centrifugo