Методология, помогающая определять разбиение модулей и связи между ними в приложении

• Обеспечивает понятность и явность архитектуры
• Обеспечивает контроль и изоляцию модулей
• Обеспечивает адаптивность под проекты

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

В соответствие с ней, становится проще поддерживать и адаптировать изменяющуюся функциональность приложений.

См. также "Требования к архитектуре"

Стандартизация проектных знаний и решений, подкрепленная обширным опытом разработки.

Методология агрегирует лучшие практики и паттерны проектирования, с адаптацией под специфику разработки фронтенд-проектов (базируясь на разделении ответственности модулей)

Ведь практик и паттернов много (SOLID, GRASP, DDD), но устоявшиеся и конкретные подходы - крайне трудно найти

См. также "Мотивация создания методологии"

Public API, Isolation, ...

Пока что пришли примерно к такому варианту

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

└── src/ ├── app/ # Инициализирующая логика приложения ├── processes/ # Процессы приложения, протекающие "над страницами" ├── pages/ # Страницы приложения ├── features/ # Ключевой функционал приложения (разбитый по фичам) ├── entities/ # Сущности ├── shared/ # Переиспользуемые модули └── index.tsx/ # Энтрипоинт приложения

└── app/ ├── store/ # Инициализация store ├── styles/ # Инициализация styles ├── hocs/ # Инициализирующая логика (HOC-обертки) ├── {...} #

└── processes/

└── pages/ ├── {page}/ # Ресурсы страницы (с минимальной логикой) └── index.tsx # Энтрипоинт (чаще всего с composed роутингом)

└── features/ # Фичи приложения └── feature-name/ # Обычно содержит в себе: ├── components/ # UI-компоненты фичи ├── {store/} # *Store фичи ├── {models/} # *Модели фичи ├── {...}/ # └── index.ts # Энтрипоинт фичи (с ее публичным API)

└── entities/ # Сущности ├── user/ # Обычно содержит в себе (по необходимости): | ├── components/ # *Подкомпоненты | ├── lib/ # *Библиотеки | ├── api/ # *Мб Подзапросы | └── store/ # *Зашаренный Стейт ├── {entity-1} # ├── {entity-2} # └── {...}/ #

└── shared/ # Переиспользуемые модули ├── ui/ # *UIKit приложения ├── lib/ # *Библиотеки приложения (вместо свалки хелперов) ├── api/ # *API-инстансы/методы └── {...} #

Не так много примеров проектов, которые полностью следуют правилам и принципам методологии, с сохранением преимуществ

Это связано с тем, что принципы вырисовывают очень идеальную архитектуру в теории, но сложную в реализации

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

• О методологии
• Об архитектуре
• Об истории методологии
• NEW: О мотивации создания методологии
• NEW: О понимании потребностей и формулировке задач
• Дискуссии по методологии

  Здесь обсуждаются и разбираются рельные примеры применения, вопросы, проблемы, идеи методологии

  Все это в совокупности влияет на спецификацию, тулкит и в целом - на дальнейшее видение и развитие методологии Т.е. все, чего пока нет в спецификации/тулките - так или иначе обсуждается в github-discussions

• NEW: О Public API сущностей
• Как можно помочь?
  • ⭐ Оцените нас на GitHub, если у вас остались положительные впечатления

    Или если по-вашему этот проект должен развиваться дальше

  • 💫 Ознакомьтесь с нашим contributing гайдом

    Важно любое содействие - от фидбека до участия в самой разработке!