[ARCHIVED] Директория для работы с бизнес-логикой

[sergeysova]

Когда идет разработка фичи или сущности, появляется код работающий чисто с логикой. Обычно этот код завязан на STM, и структура его будет сильно отличаться от проекта к проекту. Мне кажется имеет смысл сгруппировать его под одной директорией, например model.

Reference #31 (comment), #31 (comment)

Pros:

• В features, entities и shared имеется директория со своей структурой, не вылезая за пределы свой области ответственности
• Всегда очевидно где искать логику конкретного модуля
• У каждой страницы так же будет своя логика, будет размещена в model.ts

Cons:

• В процессах лежит только логика, поэтому создавать там model немного не логично

[azinit]

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

Предлагаю проголосовать, при желании - добавить

[azinit]

model

[azinit]

state

[azinit]

data

[GhostMayor]

service

[vvitto]

domain

[azinit]

Хотелось бы, чтобы была одна папка {DATA_LAYER_NAME} со всей логикой домена, а в ней уже нужные абстракции, привязанные к реализации стейт-менеджмента и к тому- как это видит разработчик/архитектор:

- feature/auth-form
    - ui/
    - {DATA_LAYER_NAME}/
         -  index.ts
         -  *thunks
         -  *effects
         -  *slice
         -  *actions
         -  *controllers
         -  *epics
         -  *context
         -  ...

[azinit]

Очевидно, да, что такой слой логики должен быть (как и ui, api, lib), при этом иметь одинаковое название, независимо от домена, в котором расположен (entities/features/pages/processes)

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

[azinit]

Если пройтись по основным вариантам:

model

• 🟩Обычно под "моделью данных" (особенно в контексте MVC) понимается слой, отвечающий за работу с данными, некой бизнес-логикой
• 🟩Слабо привязан к реализации (т.е. относительно одинаково понятно и для effector-боев, и для редаксоидов, и mobX-еров и т.д.)
• 🟥Коллизии с "модель из БД", "сущность БЛ" (entity) - и из-за этого оч часто возникают недопонимания и путанница (даже внутри нашей core-team)

store

• 🟩 Как Хранилище данных, имеющее определенную обработку экшенов, в том числе мидлвары (особенно понятно редаксоидам вроде меня)
• 🟥 Чаще всего под store подразумевается одно и единое хранилище, и потому у многих возникает разрыв понятий, когда такая папка есть в каждой фиче, entity и т.д. (хотя осуждаю, для меня кажется вполне привычным)
• 🟥 Для многих оч сильно привязано к реализации (т.е. redux), для других решений (effector/mobx/...) - уже кажется не таким очевидным

[azinit]

Лично я бы и мог почти принять model, если бы не было таких сильных пересечений с тем, что имеем уже сейчас

Если же мы оставляем ее, то можно сразу забыть

• о "популярности среди разработчиков"
• и о легком "онбординге и погружении в проект"
  т.к. непроженные методологией разрабы - не будут понимать почему
  1. есть отдельная сущность "модель" и "entity",
  2. почему кто-то говоря про модель имеет в виду работу с БЛ, а кто-то модель из БД или сущность

Раз пример

---

Два пример

А потому кажется - что ни один из текущих вариантов (store/model/data/state/controller) - не подходит до конца - и нужно что-то еще

[Postamentovich]

У нас на бекенде, слой с логикой назван service. Это как один из вариантов...

[azinit]

Ладно, меня окончательно переиграли купили этой статьей:
https://habr.com/ru/company/yandex_praktikum/blog/533702/

[azinit]

@vvitto domain

Есть ощущение, что "домен" во многом пересекается с понятием "слайс")

Т.е. это не только про бизнес-логику, но в том числе и про отображение и проч нужные вещи

Хотя в рамках эффектора возможно оч даже подошло бы