@jsunderhood Можно попросить привести более конкретный пример для типового веб приложения? Скажем, для фронт энда онлайн магазина печенек со стандартной функциональностью (список-товар-корзина-чекаут) что будет каким слоем? Сложно смапить на мою ментальную модель пока что
Да! ^_^
Недавно меня уже спрашивали в Твитере, что-куда-и-как можно вынести.
Я ответил на примере приложения с котиками 😼 twitter.com/ch_ronik/statu…
Сейчас в дополнение к котикам сделаем онлайн-магазин печенек! 🍪
Допустим, наш магазин продаёт разные виды печенек. У каждой печеньки есть цена, состав и срок изготовления.
Пользователи могут покупать печеньки на сайте, указывая предпочтения по вкусам, аллергиям, наличию молока и проч.
В доменный слой я бы вынес следующее.
- Типы печеньки и пользователя;
- функцию для подсчёта скидки на печеньку по промокодам;
- функции для определения, подходит ли печенька по вкусовым предпочтениям.
Важно, эти функции принимают данные в удобном для себя виде.
Дальше, слой адаптеров и портов. (Да, сейчас поговорим о самом внешнем слое, я в конце покажу, почему именно так: будет чуть проще увидеть разницу.)
Что у нас тут?
- UI: рендер страниц и компонентов, обработка событий;
- общение с сервером и API;
- сохранение в localStorage...
Задача адаптера — сделать интерфейс стороннего сервиса совместимым с тем, который хочет наше приложение.
Это значит, что если API отдаёт данные в виде snake_case, а мы хотим camelCase, заниматься этим будут адаптеры.
Порт — спецификация, как сторонние сервис может общаться с нашим приложением, или как наше приложение хочет, чтобы с ним общались сторонние сервисы.
Это всё был внешний слой.
Прикладной слой (между доменом и портами/адаптерами) — описывает сценарии, конкретно этого приложения.
Допустим, у нас кроме этого магазина, есть ещё проект, где печеньки просто выставляются в виде произведения искусства (их нельзя купить).
Тогда прикладной слой магазина будет содержать:
- работу со списком товаров и корзиной,
- сценарии покупки...
При этом ту часть, например, оплаты, которая использует внешний сервис (допустим, PayPal), мы вынесем в адаптер.
А в прикладном слое оставим логику, которая описывает что нужно сделать, чтобы оплата была вызвана, что нужно сделать после успешной оплаты или отклонения платежа.
@_olegkusov Ты правильно заметил, что там в основном отображение. Я дашборда не видел, поэтому сложно советовать, но кажется, что из бизнес-логики там только данные для графиков и таблиц. Рендер данных на экран — как по мне, слой адаптеров, а получение и подготовка — прикладной.
Приложение с котиками тут:
twitter.com/bespoyasov/sta…