Вопрос архитектуры - трехслойное приложение или сервисы?

[@sheermoon2012]

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

[@torrvic1156]

Спасибо вам большое за ваши бесплатные лекции Сергей! Несколько лет назад мы с моим покойным ныне (увы) отцом ехали в машине на работу и с работы и вместе слушали ваши лекции и так я начал своё вхождение в прекрасный и сложный мир программирования. Хотя и использую C#, а не Java, но ваши лекции интересны и понятны и мне. Раньше вообще слушал и даже не понимал о чём вы вообще говорите, а теперь некоторые вещи стали мне очевидны. И кстати люблю так вами нелюбимую четырехъярусную архитектуру использовать 😂Как-то круто это выглядит что-ли 😅А ещё сейчас стал практиковать Vertical Slices Architecture, где сегментирование приложения идёт по принципу features, а не по принципу технических аспектов, которые описывает Clean Architecture.

[@dmChanal1]

Можно где-то в открытом доступе увидеть пример правильно трехслойного приложения, а не 3,5? А то что-то тоже задумались и обсуждаем эту тему у себя

[@ivanaaa6049]

Один вопрос: почему на схеме стрелки зависимостей между слоями двухсторонние?

[@dickmobidick]

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

[@ivanaaa6049]

@@dickmobidick Тогда вопрос: зачем на лекции про АРХИТЕКТУРА вместо зависимостей модулей показывать потоки данных? :)

[@dickmobidick]

@@ivanaaa6049 простите, но я не понимаю, где здесь противоречие

[@lemeshenko]

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

[@Pan-ux3bq]

Трехтировое - это монолит. 3.5-тировое приложение - это частный случай гексагональной (микросервисной) архитектуры, в котором экстернализированы интерфейсы обращения к базе данных через IoC

[@tzofeolam]

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

[@vassyapupkin2841]

Правильно ли я понимаю? В трехтировой архитектуре сервисы объединяются с сущностями (dto) и тогда помимо геттеров и сеттеров в одном классе будет ещё десяток методов и класс получится очень жирным. А под сущностями можно ли понимать классы, помеченные аннотацией @Table @Entity?

[@Charnohora]

Извените, простите (мне для понимания мысли) В Спринге, так сказать, следующие лееры: вью - контроллер - сервайс - репозитори - модель (ентити). Это уже 5. DTO (дейт трансфер обдж) - это плюс один = 6. Это так, вступление. Вопрос, который с первой минуты: сервисы это ws, или леер сервайс? (я то понял о чем речь, но вижу вопрос актуальным). Заострю внимание на ДТО. В моей практие, это проброска и валидация почти ентити из вьюшки, а также, преобразование ентити к необходимой форме для ws (rest/soap). Да, ентити, которые в спринг иерархии, это, так выразиться, евангилистски правильные бизнесс структуры данных, ну как видится правильно, а не как диктует форма на вью, или пожелания того или иного интерфейса ws (когда есть рамки на этот счет). ИТОГО: вы предлогаете обьединить ентити с сервис слоем. Но, последний говорит о том что можно сделать, а ентити это просто структуры. ХМ: что можно сделать над структурой! Ну нет, а что когда целый ряд равнозначных (коллекция идентичных равных, или набор разных но равных) сущностей принимает участие в сервис слое? На кого повесим обработку поведения?

[@Charnohora]

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

[@Charnohora]

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

[@Charnohora]

Не уверен, что в 2003 году Мартин Фаулер говорил о сегодняшнем состоянии дел в Спринге. Дело в том, что вполне нормально когда ентити имеют поведение, также трансиент поля (которые не совсем поля структуры данных). Ну и валидация, там, иногда легко ее повесить на ентити, иногда проще сделать ДТО-шку. Ветоятно, тут еще и вопрос крайностей подмешан (а истина в срединке, а не по краям). ЗЫ: мне разговор интересен не в качестве доказательства точки зрения, а для поимки понимания, через диалог. Сенкс.

[@DmitriiSapronov]

А трёхтировая архитектура на спринг ложится нормально? сущности из скопа прототайп создаются (ну чтобы ссылку на дао иметь)?

[@АнтонБ-у7б]

Лайк всё ещё Сергею Немчинскому

[@DarkCooder]

Если в трех-с половинчатой модели просто наследоваться от сущностей, и уже в классах-наследниках инкапуслировать логику? А при работе с базой и API ссылаться на базовые классы? 1) Проще найти класс-наследник с реализацией 2) Меньше говнокода (сервисы, хэлперы, менеджеры итд лекго превращаются в помойку)

[@drovoseg]

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

[@seapps1]

Чувааааак, ты гений

[@torrvic1156]

Мне кажется, что это очень плохая идея. Dto только для передачи данных, а вы наследовать от Entity предлагаете. В Dto порой далеко не все свойства оригинальной Entity нужно. А если про сервис, то ему уж точно не надо наследоваться от Entity, как мне кажется и задача у него другая.

[@JashKa]

Хм... Вот более конкретные примеры было бы интересно увидеть. С кусками кода.

[@dimoonlda]

Правильно ли я понял, что в "трех-тировом" приложении для каждой сущности, которую необходимо отдавать с уровня "Интерфейс"(например, REST), необходимо создавать свой dto?

[@De1n1ol]

в "трех-тировом" приложении нет dto как таковых. dto появляется там, где от домейн модел классов сёрвисами отрезается все поведение

[@seapps1]

Правильно, но это везде на самом деле

[@AntonAndiievskyiAntonVA]

А что в видео с ограниченным доступом, которое в плейлисте предыдущее?

[@AntonAndiievskyiAntonVA]

***** а, отлично, спасибо))

[@feoktant]

Спасибо за это видео. Я думал, что кроме меня никто об этом больше не задумывался. 3,5 подход Спринга сподвиг меня в своё время просто перестать писать на Джаве. Интересно как вы считаете спустя 4 года, всё в силе?

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

мне думается, что трех с половиной архитектура включает в себя ((сущность+интерфейс) и микросервисы реализующие этот интерфейс) = "объект", при таком подходе модель будет работать в любой среде, на любом языке программирования...

[@Victorius-ua]

Случайно, не будет ли правильнее, если стрелка будет между Сущностями и Хранилищами, вместо Сервисами и Хранилищами? Просто проходил мимо :)

[@XAH20]

А куда подевались комментарии автора? И в этом, и в предыдущих видео!

[@SergeyNemchinskiy]

эм? Какие комментарии? Мои? Ютуб куда-то их потер при переезде...

[@TheMid1987]

Здравствуйте! Сергей, а что вы скажете о такой технологии, как JavaFX в плане функционирования на разных ОС? Имеет она перспективы?

[@ТимурСафаров-в1ч]

Ребята сидели и до ночи и колбасились - понятно всё с вами :)

[@rudolfsikorsky7900]

Я не очень понимаю в чём проблема хранения в БД или сериализации "обычных" объектов. Ведь и то, и другое регулируется аннотациями, которые всё равно писать. Просто недавно столкнулся с DTO и не мог понять зачем автор наплодил столько классов. Единственное что пришло в голову - чтобы классы были попроще. Но по-моему мотыляться с большим кол-вом классов ещё труднее.

[@sergeylitvinov3162]

На протяжении всей лекции мне в голову лезли всякие мысли, что проблема решается паттерном Repository

[@vesh95]

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

[@seapps1]

@@vesh95 очень просто, в репо хранятся атомарные (в контексте системы) операции. А в сервисе да, бизнес-логика

[@vesh95]

@@seapps1 А как же эвенты, которые могут поститься при сохранении сущности? Прослушиватели могут запускать процессы бизнес-логики. Тогда сервисный слой может стать ненужным звеном

[@sergeyshestakov4936]

спс

[@inspiredru]

Еще больше людей вкурили что DDD это и есть ООП.

[@zhennik263]

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

[@zamanliaman2920]

Супер!!

[@HELLO_AGAIN]

дякую

[@Pr-nj5gv]

Не в 1 раз смотрю. Но без кода не понятно о чём идёт речь.

[@denissharay8690]

Наговнокодить можно на любой архитектуре.

[@denissharay8690]

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

[@denissharay8690]

Мне для того чтобы утверждать оптыта не хватает. Я разобраться хочу. Разных людей слушаю. Вашу точку зрения учитываю.

[@danyils8728]

сдесь имеется в виду что каждый слой - это package?

[@danyils8728]

просто интересно как эта архитектура коррелирует с вот такой архитектурой. www.martinfowler.com/articles/microservices.html они дополняют друг друга или противоречат друг другу?

[@Романл-ц1ф]

А есть ли это видео в свободном доступе, спасибо?

[@smdfb7334]

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

[@gingun95]

Что полностью оопшное? Приложение на своих границах: db, rest, mq и т.д. не оопшное от слова совсем. Ооп только в слое логики и должно быть. Поддерживать конвертеры не так сложно, если код разделять по фичам (контекстам, если хотите ddd). Анемичная модель это называется, когда у тебя в слое бизнеса просто дто с геттерпми и сеттерами. Ну классно же когда бизнесс логика рамазана по сервисам (службам), особенно, когда их становится все больше, а полную картину жизненного цикла сущности собрать всё сложнее. Разделяйте код по фичам, храните бизнесс логику в доменах, а службы должны выступать лишь как аркестраторы для ваших доменов и будет вам счастье. А ещё лучше просто почитать книги о чистой архитектуре и дд, ну и вспомнить базовые принципы ооп.

[@torrvic1156]

Это вы не Vertical Slices предлагаете?

[@ScorpioT1000]

Автор топит за хиро-классы и рекламирует антипаттерны)

[@drovoseg]

Hero class? Или как-то по другому?

[@alexplishkin5811]

Какраз Anemic Model антипатерн. Не нужно забывать что такое ООП. И перестать думать в процедурном стиле. Это для процедурного стиля свойственно разделять данные и логику. Разделение данных и логики нарушает инкапсуляцию, которая говорит не только о том что данные и реализация сложного поведения должна быть скрыта, но и о том что это размещение в одном компоненте(классе) данных и методов, которые с ними работают.

[@drovoseg]

@@alexplishkin5811 Объединение данных и логики плохо работает в обычном вэбе. Инкапсуляция не нужна для классов сущностей потому как все их поля используются со стороны БД и сети.

[@ПавелМискевич-м9к]

Зашёл посмотреть только на то, что же он вычесал из своей репы на 9-ой минуте, ещё и посмотрел на это, ладно хоть не съел

[@ТимурСафаров-в1ч]

Куевый ты учитель серёга, слишком много умных слов, которрые никто не понимает. Нужно на пальцах объяснять, а не говорить самому себе понятнода.