ой не надо сейчас вводить понятие доменной модели

рано?)

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

и все же - можно ли говорить о разделении не на бизнес логику и вьюшки а на "приложение" и "интерфейс взаимодействия с приложением", то есть Application + UI

ведь у тебя может быть один и тот же юзкейс (с этим понятием ты же знаком?), с которым можно работать из разных интерфейсов (http, rabbtimq, cli)

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

вообще - если тебе скучно - почитай что есть MVC на самом деле. Тот который в 1978-ом году придумали.

ты удивишься насколько оно отличается

уже читал

ну вот в том и дело, что домен и действие как то смешиваются

ну вот в том и дело, что домен и действие как то смешиваются

что такое домен в твоем понимании?

в моем понимании это та часть приложения которая подготавливает данные для вывода

в моем понимании это та часть приложения которая подготавливает данные для вывода

вьюха тоесть

нет

респондер выводит данные не домен

давай так, приведи мне самый простой пример "домена" который ты сможешь придумать. что бы маленький был

домен только готовит

респондер выводит данные не домен

ты про ADR свой?

домен только готовит

а запись кто делает?

запись в БД?

запись в БД?

бля

бесполезно

естественно домен

ладно, давай в другой раз если тебе будет интересно но у тебя каша

в чем?

вот к чему приводит 30 лет промывания мозгов рекламами от Oracle что база данных это сердце вашего приложения

вот к чему приводит 30 лет промывания мозгов рекламами от Oracle что база данных это сердце вашего приложения

скорее практика из крудов.

да.... скорее так

вот практика крудов да

в чем?

база данных неважна. важен стэйт. инварианты стэйта. Бизнес правила и т.д.

доменную модель можно в целом поделить на две части - модель для записи и модель для чтения.

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

ок в таких терминах изменение стейта - домен

вывод - респондер

ок в таких терминах изменение стейта - домен

где будет отправка email-ов после регистрации?

в экшене или в домене?

или мы выделим отдельные сервисные сущности которые будут дергаться как-то по другому вообще и не будут входить в триаду ADR

вот это сложный вопрос, но логика говорит - домен

у меня есть подозрение, что сервисные сущности имеет смысл скармливать домену

> Domain is an entry point to the domain logic forming the core of the application, modifying state and persistence as needed. This may be a Transaction Script, Service Layer, Application Service, or something similar.

> Responder is the presentation logic to build an HTTP response from the data it receives from the Action. It deals with status codes, headers and cookies, content, formatting and transformation, templates and views, and so on.

читаем определение и думаем "что такое transactional script", "application service" и т.д.

/me конспектирует :D

/me конспектирует :D

фаулер давно законспектировал последнийц час разговоров_

скрипт естественно тут подразумевает в частности SQL

скрипт естественно тут подразумевает в частности SQL

нет.

а сервис - соответственно обертка над SQL

забудь ты просто sql)

а сервис - соответственно обертка над SQL

нет

про nosql тоже)

транзакция - это не про субд, так-то

ну так то да

фаулер давно законспектировал последнийц час разговоров_

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

ну так то да

https://martinfowler.com/eaaCatalog/transactionScript.html

https://www.bennadel.com/blog/2385-application-services-vs-infrastructure-services-vs-domain-services.htm

так...

оно как транзакции в SQL или я путаю?

оно как транзакции в SQL или я путаю?

что такое транзакция?)

сам термин

что он означает?)

блядь. да забудь ты про ACID

последовательность действий

бизнес транзакция - что это?

это при отправке заказа проверить что товар есть на складе, если нет - откатываем транзакцию ит.д.

последовательность действий

правильно, то есть никаких SQL и т.д. - все это детали реализации. Транзакционный скрипт это типа хрень которая выполняет действия

фаулер давно законспектировал последнийц час разговоров_

и Фаулер не даёт ссылок :D Но Фаулер клёвый, я согласен. Мне нравится, что у него очень взвешенный подход. Типичный многорукий специалист и это хорошо.

и Фаулер не даёт ссылок :D Но Фаулер клёвый, я согласен. Мне нравится, что у него очень взвешенный подход. Типичный многорукий специалист и это хорошо.

тебе на книжный магазин ссылок накидать?)

это при отправке заказа проверить что товар есть на складе, если нет - откатываем транзакцию ит.д.

ты когда в магазин пришел и покупаешь товар, а потом тебе звонят и "ой знаете у нас закончился потому мы откатываем транзакцию" или это по другому называется?

ERROR: S client not available

и Фаулер не даёт ссылок :D Но Фаулер клёвый, я согласен. Мне нравится, что у него очень взвешенный подход. Типичный многорукий специалист и это хорошо.

Фулер дает отсылки

тебе на книжный магазин ссылок накидать?)

ну на книги даёт, а вот видео в которых объясняется чуть по-другому - нет

это уже другой этап

и на людей ещё вроде даёт, но там есть список литературы, да

это уже другой этап

давай по другому - какие еще есть варианты делать дела помимо transactional script?

вот есть логика в контроллера. следующий этап развития - transactional script, а за ним что следует?

сервисы собственно

ох

короч

секу

https://www.youtube.com/watch?v=ajhqScWECMo

вот, ознакамливайся, тут вроде довольно просто описано

сервисы собственно

вообще рекомендую Мартин Фаулер PoEAA - очень классная книга. Маст рид

явно быстрее чем прочитать PoEAA

так пойду посмотрю а то пока что до каши дошел

?

вообще рекомендую Мартин Фаулер PoEAA - очень классная книга. Маст рид

да, маст рид

наряду с его рефакторингом

а не тратить время на маркетологов которые переименовывают вещи

явно быстрее чем прочитать PoEAA

ну там ещё и про другие вещи есть. А вообще и то и другое надо. Чем больше источников, где чуть по-разному объясняют - тем лучше оседает

маркетологи не маркетологи

ADR и MVC почти одно и то же, с некоторыми нюансами

маркетологи не маркетологи

ну типа из нашей дискуссии вырисовывается что нет никакого профита от ADR в вопросах построения приложений

в основном пока только в вопросе организации кода профит есть

в основном пока только в вопросе организации кода профит есть

пока у тебя круд

ну у меня как раз круд

есть еще веселое наблюдение - часто у людей круд просто потому что они так привыкли. И это просачивается в то как они проектируют UI. И проектируют по итогу они CRUD. что заставляет их так делать приложение. Порочный круг. И многие приложения по этой причине убогие

хм... а что не так с круд?

есть какой то пример, чтобы явно увидеть минусы?

https://kylecordes.com/2014/task-based-user-interfaces

https://www.quora.com/What-is-the-difference-between-task-based-user-interface-and-role-based-user-interface-when-designing-application

хм... а что не так с круд?

всё хорошо, когда у тебя простое приложение. То есть это оправданный подход в каких-то ситуациях.