diff --git a/dev/architecture/Single Responsibility Principle.md b/dev/architecture/Single Responsibility Principle.md index 372da80f..a60d149d 100644 --- a/dev/architecture/Single Responsibility Principle.md +++ b/dev/architecture/Single Responsibility Principle.md @@ -4,6 +4,7 @@ aliases: - принцип единственной ответственности - Single Responsibility - единственная ответственность + - единственной ответственности tags: - maturity/🌱 date: 2024-09-27 diff --git a/dev/architecture/Гранулярность микросервисов.md b/dev/architecture/Гранулярность микросервисов.md index e9038039..8b89433d 100644 --- a/dev/architecture/Гранулярность микросервисов.md +++ b/dev/architecture/Гранулярность микросервисов.md @@ -14,14 +14,14 @@ date: 2024-11-24 **Принципы определения гранулярности** 1. **Бизнес-ориентированность**. Микросервис должен отражать конкретный бизнес-процесс или функциональную область. Если сервис охватывает слишком много бизнес-логики, его стоит разделить на более специализированные компоненты. Например, в системе для интернет-магазина логика управления заказами и обработка платежей должны быть разделены на два сервиса. -2. **Правило единственной ответственности**. Каждый микросервис должен выполнять одну задачу и делать это хорошо. Если сервис отвечает за множество разнородных функций, вероятно, его стоит разделить. Например, сервис, отвечающий и за авторизацию, и за управление профилем пользователя, нарушает принцип единственной ответственности. -3. **Слабая связанность и высокая когезия**. Сервисы должны быть слабо связаны друг с другом, чтобы изменения в одном не требовали изменений в других. В то же время внутренняя логика сервиса должна быть максимально когерентной — все функции должны быть тесно связаны и иметь смысл как единое целое. +2. Правило [[Single Responsibility Principle|единственной ответственности]]. Каждый микросервис должен выполнять одну задачу и делать это хорошо. Если сервис отвечает за множество разнородных функций, вероятно, его стоит разделить. Например, сервис, отвечающий и за авторизацию, и за управление профилем пользователя, нарушает принцип единственной ответственности. +3. Слабая [[связанность]] и высокая [[Связность|связность]]. Сервисы должны быть слабо связаны друг с другом, чтобы изменения в одном не требовали изменений в других. В то же время внутренняя логика сервиса должна быть максимально когерентной — все функции должны быть тесно связаны и иметь смысл как единое целое. 4. **Коммуникационные накладные расходы**. При излишнем разделении микросервисов коммуникация между ними может стать значительной проблемой. Каждое взаимодействие требует сетевых запросов, которые увеличивают время отклика и усложняют тестирование. Избежать этого можно, объединяя сервисы, которые часто взаимодействуют друг с другом. 5. **Масштабируемость и независимость деплоя**. Один из ключевых факторов в пользу микросервисов — возможность масштабировать и развертывать сервисы независимо друг от друга. При этом важно помнить, что слишком мелкие микросервисы могут превратиться в головную боль для команды DevOps из-за увеличения количества деплоя и инфраструктурных задач. **Подходы к выбору гранулярности** -- **Разбиение по доменным областям**. Этот подход предполагает разделение микросервисов по бизнес-доменам. Например, в системе для электронной коммерции могут существовать отдельные сервисы для управления каталогом товаров, работы с корзиной и обработкой платежей. -- **Использование событий**. Событийная архитектура позволяет разделять микросервисы на основе того, как данные движутся через систему. Это помогает уменьшить связанность, так как каждый сервис реагирует только на те события, которые ему необходимы. +- Разбиение по [[Доменная область|доменным областям]]. Этот подход предполагает разделение микросервисов по бизнес-доменам. Например, в системе для электронной коммерции могут существовать отдельные сервисы для управления каталогом товаров, работы с корзиной и обработкой платежей. +- **Использование событий**. [[../../../../_inbox/Событийно-ориентированное программирование|Событийная архитектура]] позволяет разделять микросервисы на основе того, как данные движутся через систему. Это помогает уменьшить связанность, так как каждый сервис реагирует только на те события, которые ему необходимы. - **Практика "Strangler Fig"**. Этот метод подразумевает постепенное выделение функциональности из монолита в микросервисы. Это помогает определить оптимальную гранулярность, анализируя, какие части системы требуют частых изменений и могут быть разделены без излишних коммуникационных накладных расходов. **Ошибки, которых следует избегать** diff --git a/dev/architecture/Доменная область.md b/dev/architecture/Доменная область.md index 0d397a79..9b2537f5 100644 --- a/dev/architecture/Доменная область.md +++ b/dev/architecture/Доменная область.md @@ -2,6 +2,7 @@ aliases: - домена - доменных областях + - доменным областям tags: - maturity/🌱 date: 2024-09-27 diff --git a/dev/architecture/Связность.md b/dev/architecture/Связность.md index 631a9151..cb5ad6d6 100644 --- a/dev/architecture/Связность.md +++ b/dev/architecture/Связность.md @@ -2,6 +2,7 @@ aliases: - Cohesion - связности + - связность tags: - maturity/🌱 date: 2024-11-24