Аспект проектирования при основных типах методологий разработки программных систем:

Каскад (waterfall) - заказчик дает четкие требования, по ним строится архитектура системы, программисты делают по ней код.

Гибкая (agile, XP, итеративная) - заказчик дает общие требования, по ним строится прототип архитектуры системы, программисты делают по ней код, систему показывают заказчику, вносятся корректировки, выпускается следующая версия и.т.д по кругу.

DDD (domain-driven design, предметно-ориентированная проектирование) - заказчик и программисты постоянно тесно работают над выработкой четкой модели предметной области, которая затем практически один в один становится скелетом архитектуры программной системы.

Каскад применяется для более-менее типовых задач и когда есть четкие требования (SRS, техзадание).
DDD увеличивает вероятность успеха при решении сложных задач, с нечеткими и меняющимися требованиями и необходимостью исследования предметной области.

#architecture

Чистая архитектура (Clean Architecture) — это способ разделения функционала по степени его близости к предметной области приложения.

Она даёт:

- Независимость от зависимостей. Архитектура вашей системы не зависит напрямую от существования какой-либо библиотеки. Это позволяет использовать фреймворки как инструменты, а не втискивать свою систему в их рамки.

- Тестируемость. Бизнес-правила можно тестировать без UI, базы данных, веб-сервера или любого другого внешнего элемента.

- Независимость от UI. Пользовательский интерфейс можно легко изменить. Например, веб-интерфейс может быть заменен на мобильный, без изменения бизнес-правил.

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

Именно по рекомендациями Clean architecture не следует обращаться к web API напрямую из стора. Подобные требования есть у многих методологий проектирования ПО

#architecture #cleanarchitecture

Мир IT крутится вокруг данных. Если задуматься, 99.999% времени любой компьютер внутри себя просто перекладывает данные с одного места в другое.

Data pipeline (конвейер данных) - это методика сбора, обработки и анализа данных, которые сперва собираются из разных источников в хранилища, структурируются и затем используются для разных целей.

В data lake складывают неструктурированные данные, data warehouse - уже структурированные, удобные для запросов.

#data #architecture

Для любителей FSD описание проекта на Vue на нем (тудушка)

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

#fsd #architecture

Аргументация против глобальных автоимпортов (типа тех, что в Nuxt) от Artyom Tuchkov

1. Это явно - ты всегда видишь, откуда взялся компонент и в один клик можешь провалиться в него, а не в *.d.ts ;)

2. Это наглядно видно не только в редакторе, но и на всяких гитхабах, когда смотришь там код, с автоимпортами тебе придется гадать, откуда взялся компонент

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

4. Не нужно генерировать портянку *.d.ts для того, чтобы редакторы видели их, и, как следствие, без них ты получаешь более качественный тулинг и анализ твоего кода

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

6. Импорты может проставлять сама IDE, а еще их можно сворачивать в 1 строку, если визуально отвлекают

#architecture #bestpractices #tip #nuxt