#архитектура #solid #новые_подходы #simple
Приветствую 👋
У меня для вас большой блок информации для осмысления и анализа.
Все, кто интересуется архитектурой приложений, знают и стараются опираться на принципы SOLID и паттерны проектирования.
Впервые принципы SOLID были представлены в 2000 году в статье Design Principles and Design Patterns Роберта Мартина, также известного как Дядюшка Боб.
https://web.archive.org/web/20150906155800/http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
С тех пор прошло: 24 года.
Паттерны проектирования были адаптированы в 1987 году под язык SmallTalk Кентом Бэком и Вардом Каннингемом.
https://c2.com/doc/oopsla87.html
С тех пор прошло: 37 лет.
Предлагаю рассмотреть альтернативный подход, базирующийся на Composition Tree и концепции реактивного программирования.
Подход направлен на улучшение масштабируемости, поддержания чистоты кода, учитывая прогресс современных языков.
❗При разработке серьезных проектов тех руководитель должен решать задачу многокритериальной оптимизации:
- минимизация сроков разработки
- сдерживание роста кривой сложности доработок
- сохранение максимального уровня чистоты кода (понятность, читабельность, разделение на слои, и т.д.)
- контролируемость технического долга
- рост компетентности сотрудников
- bus фактор в отделе разработки > 1.
Предлагаемый подход позволяет решить такую задачу.
Напомню ключевые моменты Composition Tree. ⬇️
Каждое приложение начинает свою работу с определенной точки, называемой точкой входа (Entry Point).
Из данной точки происходит дальнейшее разветвление и исполнение кода.
Структура этого разветвления похожа на дерево и называется Composition Tree.
Места, где происходит разветвление, называются вершинами/узлами.
Самая первая вершина - это Entry Point.
В вершинах дерева осуществляется создание или получение необходимых компонентов и зависимостей.
Здесь же устанавливаются связи между различными частями приложения, такими как бизнес-логика, пользовательский интерфейс, сервисы и прочее.
Каждая вершина в дереве включает в себя контекст, который содержит все необходимые зависимости для данного участка кода.
Узлы или вершины в дереве соединены между собой через их контексты.
Продолжение 👇
Приветствую 👋
У меня для вас большой блок информации для осмысления и анализа.
Все, кто интересуется архитектурой приложений, знают и стараются опираться на принципы SOLID и паттерны проектирования.
Впервые принципы SOLID были представлены в 2000 году в статье Design Principles and Design Patterns Роберта Мартина, также известного как Дядюшка Боб.
https://web.archive.org/web/20150906155800/http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
С тех пор прошло: 24 года.
Паттерны проектирования были адаптированы в 1987 году под язык SmallTalk Кентом Бэком и Вардом Каннингемом.
https://c2.com/doc/oopsla87.html
С тех пор прошло: 37 лет.
Предлагаю рассмотреть альтернативный подход, базирующийся на Composition Tree и концепции реактивного программирования.
Подход направлен на улучшение масштабируемости, поддержания чистоты кода, учитывая прогресс современных языков.
❗При разработке серьезных проектов тех руководитель должен решать задачу многокритериальной оптимизации:
- минимизация сроков разработки
- сдерживание роста кривой сложности доработок
- сохранение максимального уровня чистоты кода (понятность, читабельность, разделение на слои, и т.д.)
- контролируемость технического долга
- рост компетентности сотрудников
- bus фактор в отделе разработки > 1.
Предлагаемый подход позволяет решить такую задачу.
Напомню ключевые моменты Composition Tree. ⬇️
Каждое приложение начинает свою работу с определенной точки, называемой точкой входа (Entry Point).
Из данной точки происходит дальнейшее разветвление и исполнение кода.
Структура этого разветвления похожа на дерево и называется Composition Tree.
Места, где происходит разветвление, называются вершинами/узлами.
Самая первая вершина - это Entry Point.
В вершинах дерева осуществляется создание или получение необходимых компонентов и зависимостей.
Здесь же устанавливаются связи между различными частями приложения, такими как бизнес-логика, пользовательский интерфейс, сервисы и прочее.
Каждая вершина в дереве включает в себя контекст, который содержит все необходимые зависимости для данного участка кода.
Узлы или вершины в дереве соединены между собой через их контексты.
Продолжение 👇
🔥5
#архитектура #solid #новые_подходы #simple
Итак рассмотрим подход на базе Composition Tree и концепции реактивного программирования.
❗Подход включает в себя 6 основных принципов, название каждого из которых образует аббревиатуру SIMPLE.
Рассмотрим каждый из принципов:
S - Принцип разделения на основе потоков данных (Stream-based Segregation Principle):
Потоки данных описываются как последовательности событий или значений, которые меняются со временем.
В реактивном программировании потоки данных играют ключевую роль.
Принцип разделения на основе потоков данных подразумевает, что классы в приложении должны быть организованы вокруг потоков данных, которые они обрабатывают, обеспечивая тем самым отзывчивость и простоту управления состоянием.
Основой могут быть реактивные объекты: ReactiveProperty, ReactiveCommand.
I - Независимость от интерфейсов в бизнес-логике (Interface Free In Business Logic Principle):
Бизнес-логика должна быть свободна от традиционных интерфейсов, предпочитая вместо этого изменения и подписки на потоки данных для взаимодействия классов.
Это облегчает динамичное взаимодействие между классами и улучшает отзывчивость приложения.
‼️При этом слой сервисов и внешних библиотек допускает использование интерфейсов.
M - Модульное разделение (Modular Decoupled Principle):
В приложении должно быть четкое разделению ответственности между различными модулями, аналогично принципу единственной ответственности из SOLID.
Это подразумевает независимость бизнес-логики, пользовательского интерфейса, сетевых запросов и других частей приложения.
P - Принцип проактивной предсказуемости (Proactive Predictability Principle):
Системы, построенные с использованием реактивного подхода, должны обеспечивать легкость предсказания поведения и взаимодействий потоков данных.
Это требует четкой структуризации и отслеживания зависимостей, что упрощает тестирование и отладку.
Все потоки данных должны иметь чёткое назначение и иметь только необходимую ответственность.
L - Независимость слоёв (Layered-Independent Principle):
Используется слоистый подход к архитектуре, в котором каждый слой (UI, бизнес-логика, данные и др.) работает независимо, что повышает модульность и упрощает тестирование.
Слой в архитектуре приложений - это логическое разделение классов приложения, которое обеспечивает разграничение функциональности.
Каждый слой отвечает за определенную область задач и обладает своей ответственностью в контексте многоуровневой архитектуры.
❗Основных слоёв - 7:
- Entity Layer (вершина дерева Composition Tree)
- Presentation Model Layer (слой бизнес-логики)
- View Layer (слой представления)
- Service Layer (слой сервисов)
- Communication Layer (слой связей)
- Content/Data Layer (слой контента/данных)
- State Layer (слой состояний).
Вспомогательными слоями могут выступать сторонние библиотеки.
E - Закрытая инкапсуляция (Enclosed Encapsulation Principle):
Методы и переменные классов бизнес-логики приложения должны быть максимально закрыты (с модификатором доступа "private").
Это снижает зависимость между различными частями кода и упрощает поддержку и изменение приложения.
Благодарю за внимание!
Жду ваши вопросы в комментариях!
Хороших выходных 🖐️
Итак рассмотрим подход на базе Composition Tree и концепции реактивного программирования.
❗Подход включает в себя 6 основных принципов, название каждого из которых образует аббревиатуру SIMPLE.
Рассмотрим каждый из принципов:
S - Принцип разделения на основе потоков данных (Stream-based Segregation Principle):
Потоки данных описываются как последовательности событий или значений, которые меняются со временем.
В реактивном программировании потоки данных играют ключевую роль.
Принцип разделения на основе потоков данных подразумевает, что классы в приложении должны быть организованы вокруг потоков данных, которые они обрабатывают, обеспечивая тем самым отзывчивость и простоту управления состоянием.
Основой могут быть реактивные объекты: ReactiveProperty, ReactiveCommand.
I - Независимость от интерфейсов в бизнес-логике (Interface Free In Business Logic Principle):
Бизнес-логика должна быть свободна от традиционных интерфейсов, предпочитая вместо этого изменения и подписки на потоки данных для взаимодействия классов.
Это облегчает динамичное взаимодействие между классами и улучшает отзывчивость приложения.
‼️При этом слой сервисов и внешних библиотек допускает использование интерфейсов.
M - Модульное разделение (Modular Decoupled Principle):
В приложении должно быть четкое разделению ответственности между различными модулями, аналогично принципу единственной ответственности из SOLID.
Это подразумевает независимость бизнес-логики, пользовательского интерфейса, сетевых запросов и других частей приложения.
P - Принцип проактивной предсказуемости (Proactive Predictability Principle):
Системы, построенные с использованием реактивного подхода, должны обеспечивать легкость предсказания поведения и взаимодействий потоков данных.
Это требует четкой структуризации и отслеживания зависимостей, что упрощает тестирование и отладку.
Все потоки данных должны иметь чёткое назначение и иметь только необходимую ответственность.
L - Независимость слоёв (Layered-Independent Principle):
Используется слоистый подход к архитектуре, в котором каждый слой (UI, бизнес-логика, данные и др.) работает независимо, что повышает модульность и упрощает тестирование.
Слой в архитектуре приложений - это логическое разделение классов приложения, которое обеспечивает разграничение функциональности.
Каждый слой отвечает за определенную область задач и обладает своей ответственностью в контексте многоуровневой архитектуры.
❗Основных слоёв - 7:
- Entity Layer (вершина дерева Composition Tree)
- Presentation Model Layer (слой бизнес-логики)
- View Layer (слой представления)
- Service Layer (слой сервисов)
- Communication Layer (слой связей)
- Content/Data Layer (слой контента/данных)
- State Layer (слой состояний).
Вспомогательными слоями могут выступать сторонние библиотеки.
E - Закрытая инкапсуляция (Enclosed Encapsulation Principle):
Методы и переменные классов бизнес-логики приложения должны быть максимально закрыты (с модификатором доступа "private").
Это снижает зависимость между различными частями кода и упрощает поддержку и изменение приложения.
Благодарю за внимание!
Жду ваши вопросы в комментариях!
Хороших выходных 🖐️
🔥11