Основное отличие в том, что ДДД и ЭШ требует вовлеченности и "образованности" большого количества людей, а это не всегда возможно. Для этих случаев я и разработал декомпозицию на базе эффектов, которую может выполнить один человек и которая даёт достаточно хорошие результаты.
упрощенная до трехзвенной модель.
Это совсем не так:)
Способ реализации не зашит ни в концептуальную модель, ни в подход к декомпозиции и спроектированная таким образом система может быть реализована как угодно - я предпочитаю функциональную архитектуру, но не вижу никаких препятствий к тому, чтобы реализовать её хоть в виде гексагональной, хоть cqrs/вертикальной, хоть той же трёхзвенной модели. Надеюсь вы имели ввиду трёхуровневую архитектуру (более привычнй мне термин), а не трёхзвенную уголовную модель в казахстане ?
Для программирования не специфично, но в программировании есть свои ограничения, которые исходят из требований и планов/перспектив развития, и без приземления на них выбрать решение невозможно.
Ну и мне всё больше кажется, что вы говорите о "проблеме выражения". Плюс вспомнил ООПный способ её решения
За книжку - спасибо, добавил себе в список прочтения.
Может быть после неё я уже наконец всё пойму и соглашусь с тем, что ООП хорошее средство для моделирования реальности :trollface:
Я собственно и пошёл изобретать велосипед, т.к. я не понимаю, как проектировать системы через моделирование реальности. А вот как проектировать системы через операции и ресурсы - я понимаю
Я не могу понять "требования" за этим кодом. Все 4 операции доступны для конечного пользователя? Операции записи и печати как-то связанны между собой? Например печать берёт отчёт, ранее записанный в базу? Откуда берётся отчёт для записи в базу?
А вообще ваша задача очень похожа на проблему выражения у которой нет хорошего решения. А как из возможных решений выбирать, зависит опять же от требований и кофейной гущи - что чаще у вас будет появляться, новые данные или новые операции?
Ссылочная целостность данных обеспечивается на уровне СУБД. Проще писать миграции. Проще потом работать с этими данными, строить аналитику и т.п.
Пока что, на уровне СУБД я тоже до последнего стараюсь сохранить общую схему с внешними ключами - я изолирую только код, если у меня нет чёткого понимания когда и почему я буду пилить систему на отдельные сервисы.
Да, и распиливание на отдельные проекты или тем более микросервисы особо ничего не даёт.
А вот тут не согласен. Возможно, дело в личном опыте, но мой говорит, что нарезка даёт очень многое. Если для каждого бита информации нет одного явного места, откуда с ним можно работать и это ограничение не реализовано технически, то очень быстро весь код начинает работать со всей схемой. А в след за этим идёт экспоненциальный рост стоимости разработки, из-за кучи регрессий в неожиданных местах, "волновых эффектах", когда изменение в одной таблице требует изменений во всей кодовой базе.
А, во-вторых, и это наверное даже более важная причина, за схему данных должен отвечать один человек.
Тут я в целом с вами согласен, но зависит от масштабов. У меня нет отсечки в таблицах, но в есть в людях - имхо, при появлении пятого бакэндера в команде надо начинать всё пилить пополам - команду, схему, систему. И там за схему снова будет отвечать один человек.
А в идеале ещё и распиленными на отдельные микросервисы. Обычно это доходит до полного абсурда, когда, например, 3 отдельных микросервиса: пользователи, товары, заказы.
Угу, мне прямо щяс такой легась прилетел, последний баг отлаживал запустив 6 (шесть) микросервисов. Надеюсь продать идею тотального реинженеринга:) Так вот я даже на уровне модулей не это предлагаю, боже упаси - моя идея в том, чтобы провести "транзакционный анализ" и в идеале так нарезать систему, чтобы в выполнении любой транзакции задействовался код только одного модуля.
С одной стороны, против *Controller, *Repo, *DTO я ничего не имею.
С другой стороны *Service - ну как-то так... Не ООП-но и в итоге это часто превращается ПП-подход с процедурами внутри сервисов и структурами данных в сущностях.
С другой стороны, этот суффикс действительно удобен. В результате я для себя пришёл к такой схеме - я нарезаю проект на подсистемы, интерфейс каждой подсистемы определяется классом *Service, а имена вспомогательных классов для реализации этой подсистемы разработчик определяет сам.
Не придуман еще тот язык, на котором можно выразить необходимость явно сохранять изменения в базу или, наоборот, нежелательность при том, что метод есть.
Не уверен, что правильно вас понял, но возможно есть такой язык - Haskell. Если дали IO-монаду - надо сохранять, не дали - не надо:)
Зато придуманы юнит-тесты
У меня в черновике была заметка про тесты, но я решил убрать её, чтобы не размывать фокус поста:)
Проблема Артемия была в том, что он был сторонником лондонской школы тестирования, тестировал отдельные методы, а в тестах сервиса репозитории замокал.
После этого случая он стал сторонником детроицкой школы тестирования и больше у него таких проблем не будет:)
И вот тут я процитирую один комментарий с сайта Роберта Мартина:
А почему вы не цитируете ответ Мартина?:)
You begin by talking about OOD and by the end of the first paragraph have made the most critical of errors: equating OOD with OOP. OOA/D is about THINKING. OOP is about DOING. The two are separate.
* It took me over half a decade to realize that this wasn't true. OOP and OOD are inseparable. OOA is undefined.- UB
К сожалению сама картинка здоровая получилась, а хабр, кажется, не может нормально увеличивать в превью. Могу предложить открыть по прямой ссылке - у меня в ФФ она нормально масштабируется
Ну и с альтернативами, по моему опыту, новичёк скорее просто не сможет решить задачу и придёт с вопросом.
А в JPA новичёк вполне может с полной уверенностью в себе решить задачу, но попутно разложить гору грабель, которые в тесте будут тихонько лежать, а в проде начнут больно бить, если ревью проскочат.
Ну, ваш пост не портит даже то, что вы декларируете ненависть к хибернейту в самом начале.
Спасибо:)
я склонен игнорировать предложения работы, где мне либо предлагают нелюбимые технологии
Да, согласен с вами, но мне кажется, что разработчиков, которые могут и согласны работать с JPA существенно больше тех, кто могут и согласны работать с Spring Data JDBC/jooq и т.п.
Другое дело (опять же имхо), что благодаря простоте их устройства, знание этих технологий не обязательно при найме - даёшь человеку день прочитать мануал и он уже способен их использовать на вменяемом уровне, месяц чуть пристальнее смотришь на ревью и всё, эксперт готов.
Во-первых ещё раз обращу ваше внимание, что это первая версия и в ней действительно могут быть противоречия.
Во-вторых я ещё помедитирую на эту тему, но сходу я не вижу противоречия - при смене реализации, структура диаграммы сохранится, изменятся только тексты внутри блоков.
Но тут действительно есть над чем подумать - кажется надо как-то разделить поведение, которое наблюдаемо через взаимодействия с ресурсами внешних систем (которые фиксированы и не могут изменяться) и поведение, которое наблюдаемо через изменение результатов эффектов чтения внутренних ресурсов (и тут не важно как этот ресурс реализован).
В любом случае, думаю вы правы, в том, что надо разделить краткую и полную нотацию. У них разные контексты и цели.
Взгляд все же предполагает некоторое исследование, доказательства и т.п
я как минимум ожидаю, что будут приведены явные и несомненные плюсы ORM
Тогда вам, возможно, больше понравится мой пост против JPA, где я и признаю бесспорные плюсы JPA, и, на мой взгляд, аргументированно критикую её подход.
Есть ещё черновик поста с критикой подхода к моделированию данных связным графом объектом.
В качестве альтернативы я предлагаю использовать Агрегаты и Spring Data JDBC.
К текущему моменту, я применил Spring Data R2/JDBC в 4 коммерческих проектах, есть определённы сложности (больше всего не хватает Specification), но в целом доволен и намерен и дальше использовать их в качестве технологии работы с БД по умолчанию.
У меня каждый воркспейс — это отдельный "проект". А на стандартный набор окон (браузер, терминал, саблайм, файловый менеджер) навешены шорткаты, которые их разворачивают/сворачивают:) Плюс есть шоткат который работает с "прочими" окнами которые, как правило это как раз являются тулами для работы над "проектом" данного воркспейса (IDE, скайп, почта).
А виджетами/запускалками я не пользуюсь.
Т.е. изменилось только то, что я свой чудо-скрипт написал:)
Это не совсем так.
Основное отличие в том, что ДДД и ЭШ требует вовлеченности и "образованности" большого количества людей, а это не всегда возможно. Для этих случаев я и разработал декомпозицию на базе эффектов, которую может выполнить один человек и которая даёт достаточно хорошие результаты.
Это совсем не так:)
Способ реализации не зашит ни в концептуальную модель, ни в подход к декомпозиции и спроектированная таким образом система может быть реализована как угодно - я предпочитаю функциональную архитектуру, но не вижу никаких препятствий к тому, чтобы реализовать её хоть в виде гексагональной, хоть cqrs/вертикальной, хоть той же трёхзвенной модели. Надеюсь вы имели ввиду трёхуровневую архитектуру (более привычнй мне термин), а не трёхзвенную уголовную модель в казахстане ?
Для программирования не специфично, но в программировании есть свои ограничения, которые исходят из требований и планов/перспектив развития, и без приземления на них выбрать решение невозможно.
Ну и мне всё больше кажется, что вы говорите о "проблеме выражения". Плюс вспомнил ООПный способ её решения
За книжку - спасибо, добавил себе в список прочтения.
Может быть после неё я уже наконец всё пойму и соглашусь с тем, что ООП хорошее средство для моделирования реальности :trollface:
Я собственно и пошёл изобретать велосипед, т.к. я не понимаю, как проектировать системы через моделирование реальности. А вот как проектировать системы через операции и ресурсы - я понимаю
Я не могу понять "требования" за этим кодом. Все 4 операции доступны для конечного пользователя? Операции записи и печати как-то связанны между собой? Например печать берёт отчёт, ранее записанный в базу? Откуда берётся отчёт для записи в базу?
А вообще ваша задача очень похожа на проблему выражения у которой нет хорошего решения. А как из возможных решений выбирать, зависит опять же от требований и кофейной гущи - что чаще у вас будет появляться, новые данные или новые операции?
промахнулся
или нет?♂️
Вам спасибо за комментарий:)
Пока что, на уровне СУБД я тоже до последнего стараюсь сохранить общую схему с внешними ключами - я изолирую только код, если у меня нет чёткого понимания когда и почему я буду пилить систему на отдельные сервисы.
А вот тут не согласен. Возможно, дело в личном опыте, но мой говорит, что нарезка даёт очень многое. Если для каждого бита информации нет одного явного места, откуда с ним можно работать и это ограничение не реализовано технически, то очень быстро весь код начинает работать со всей схемой. А в след за этим идёт экспоненциальный рост стоимости разработки, из-за кучи регрессий в неожиданных местах, "волновых эффектах", когда изменение в одной таблице требует изменений во всей кодовой базе.
Тут я в целом с вами согласен, но зависит от масштабов. У меня нет отсечки в таблицах, но в есть в людях - имхо, при появлении пятого бакэндера в команде надо начинать всё пилить пополам - команду, схему, систему. И там за схему снова будет отвечать один человек.
Угу, мне прямо щяс такой легась прилетел, последний баг отлаживал запустив 6 (шесть) микросервисов. Надеюсь продать идею тотального реинженеринга:) Так вот я даже на уровне модулей не это предлагаю, боже упаси - моя идея в том, чтобы провести "транзакционный анализ" и в идеале так нарезать систему, чтобы в выполнении любой транзакции задействовался код только одного модуля.
Я с вами частично согласен, частично нет.
С одной стороны, против *Controller, *Repo, *DTO я ничего не имею.
С другой стороны *Service - ну как-то так... Не ООП-но и в итоге это часто превращается ПП-подход с процедурами внутри сервисов и структурами данных в сущностях.
С другой стороны, этот суффикс действительно удобен. В результате я для себя пришёл к такой схеме - я нарезаю проект на подсистемы, интерфейс каждой подсистемы определяется классом *Service, а имена вспомогательных классов для реализации этой подсистемы разработчик определяет сам.
Не уверен, что правильно вас понял, но возможно есть такой язык - Haskell. Если дали IO-монаду - надо сохранять, не дали - не надо:)
У меня в черновике была заметка про тесты, но я решил убрать её, чтобы не размывать фокус поста:)
Проблема Артемия была в том, что он был сторонником лондонской школы тестирования, тестировал отдельные методы, а в тестах сервиса репозитории замокал.
После этого случая он стал сторонником детроицкой школы тестирования и больше у него таких проблем не будет:)
Добавил переводы, спасибо
Бесстыжий плаг
С одной стороны я с вами согласен - многие принципы, включая солид, действительно слишком абстрактные.
С другой стороны есть вполне конкретные - принцип ацикличных зависимостей, например.
Согласованный набор таких принципов я пытаюсь собрать в Эргономичном подходе: https://azhidkov.pro/posts/22/04/220409-ergo-approach-v10m1/
А почему вы не цитируете ответ Мартина?:)
Но вообще я с вами согласен ООП != ООД.
К сожалению сама картинка здоровая получилась, а хабр, кажется, не может нормально увеличивать в превью. Могу предложить открыть по прямой ссылке - у меня в ФФ она нормально масштабируется
Ну и с альтернативами, по моему опыту, новичёк скорее просто не сможет решить задачу и придёт с вопросом.
А в JPA новичёк вполне может с полной уверенностью в себе решить задачу, но попутно разложить гору грабель, которые в тесте будут тихонько лежать, а в проде начнут больно бить, если ревью проскочат.
Спасибо:)
Да, согласен с вами, но мне кажется, что разработчиков, которые могут и согласны работать с JPA существенно больше тех, кто могут и согласны работать с Spring Data JDBC/jooq и т.п.
Другое дело (опять же имхо), что благодаря простоте их устройства, знание этих технологий не обязательно при найме - даёшь человеку день прочитать мануал и он уже способен их использовать на вменяемом уровне, месяц чуть пристальнее смотришь на ревью и всё, эксперт готов.
мастер йода деткед?♂️
Вам спасибо за комментарий - я узнать рад, что вы нашли пост полезным:)
Спасибо за замечание
Во-первых ещё раз обращу ваше внимание, что это первая версия и в ней действительно могут быть противоречия.
Во-вторых я ещё помедитирую на эту тему, но сходу я не вижу противоречия - при смене реализации, структура диаграммы сохранится, изменятся только тексты внутри блоков.
Но тут действительно есть над чем подумать - кажется надо как-то разделить поведение, которое наблюдаемо через взаимодействия с ресурсами внешних систем (которые фиксированы и не могут изменяться) и поведение, которое наблюдаемо через изменение результатов эффектов чтения внутренних ресурсов (и тут не важно как этот ресурс реализован).
В любом случае, думаю вы правы, в том, что надо разделить краткую и полную нотацию. У них разные контексты и цели.
Бесстыжий плаг
Тогда вам, возможно, больше понравится мой пост против JPA, где я и признаю бесспорные плюсы JPA, и, на мой взгляд, аргументированно критикую её подход.
Есть ещё черновик поста с критикой подхода к моделированию данных связным графом объектом.
В качестве альтернативы я предлагаю использовать Агрегаты и Spring Data JDBC.
К текущему моменту, я применил Spring Data R2/JDBC в 4 коммерческих проектах, есть определённы сложности (больше всего не хватает Specification), но в целом доволен и намерен и дальше использовать их в качестве технологии работы с БД по умолчанию.
Вам спасибо за комментарий, рад что статья оказалась полезной для вас:)
У меня каждый воркспейс — это отдельный "проект". А на стандартный набор окон (браузер, терминал, саблайм, файловый менеджер) навешены шорткаты, которые их разворачивают/сворачивают:) Плюс есть шоткат который работает с "прочими" окнами которые, как правило это как раз являются тулами для работы над "проектом" данного воркспейса (IDE, скайп, почта).
А виджетами/запускалками я не пользуюсь.
Т.е. изменилось только то, что я свой чудо-скрипт написал:)