Please enable JavaScript.
Coggle requires JavaScript to display documents.
Fundamentals of software architecture - Coggle Diagram
Fundamentals of software architecture
Introduction
Про важное, чтобы это не было
Майндмап архитектора
Ожидания
Принимать архитектурные решения
Постоянный анализ архитектуры
Следить за state of art/Кругозор
Архнадзор
Бизнес-домен
Навыки общения
Политика
Определение
Решения
ADR
Характеристики
Принципы дизайна
Неконкретный гайдлайн
Структура
Пересечения
Инженерные практики
Эволюцонная архитектура
DevOps
Процессы :
Данные
Preface
Инвалидация аксиом
Trade-off
Разработка должна стать инженерной дисциплиной
Architectural thinking
Architecture vs design
Mentoring
Collaboration
Technical path
Architect
Breadth
Не должен знать многого глубоко, но должен знать широко тренды и разные решения
Developer
Depth
Analyzing Trade-Offs
Everything is a Trade-Off
Example: pub-sub vs p2p
Business Drivers
NFR/required architecutre characteristics (-ilities)
Architecture/Hands-On Balance
Non-critical tasks to avoid bottleneck
POCs
Production-grade
Tools
Bug-fixes
If not writing code at least involved
Modularity
Measuring
Cohesion
Какой код должен быть в одном модуле
Functional
Sequential
Communicational
Procedural
Temporal
Logical
Coincidential
LCOM
Coupling
Afferent — incoming
utils
Efferent — outgoing
Я завишу от кого-то — у меня efferent coupling с кем-то
presentation
Instability
Connascense
Abstractness
Distance from the Main Sequence
Zone of uselessness
Zone of pain
Группировка родственного кода
Пакеты/неймспейсы и т. д.
Архитектурные характеристики
Критерии
Недоменные соображения
нефункциональные требования - так себе термин
Сложно выразить и определить
Влияние на структурные аспекты
Критичные
Меньше - лучше
Целимя не в лучшую, а в наименее плохую
итеративность
Как определить
Domain concern
Требования
Каты
Особенности поведения
Явные и неявные характеристики
Определяйте не самое важное, а самое не важное
Оценка и управление
Структурные - статические
Цикломатическая сложность
Процессные
Fitness Functions
Операционные оценки
Скоуп
Connascence
Статическое
Динамическое
Квант
Синхронное
Асинхронное
Квант
Определение
Независимый деплой
High functional cohesion
Synchronous connascence
Компонентное мышление
Партиционирование
Слои
Modular Monolith
Идентификация компонентов
Инит
Требования распихать по компонентам
Анализ ролей и ответственности
Анализ характеристик
Реструктурировать. Повторить.
дизайн
Entity trap
Actor-Actions
Entity Storm
Workflow approach
Architecture Styles
Fundamental pattern
Big ball of mud
Unitary architecture
Client/server
2-tier, 3-tier
monolitic vs distributed
trade-offs of distributed
fallacies
distributed logging
distributed transactions
BASE
contract maintenance and versioning
Monolitic
Layered architecture
Pipeline architecture
Microkernel
InProcess
RPC/REST
Contracts matter!
Could be both domain- and technically partitioned
Distributed
Service-Based
shared (single) database
logical separation
ACID
data-access libraries common and domain
multiple deployments
1 to many quants
Event-Driven
broker (bus по Уди)
problems
monitoring
error handling
redelivery
mediator (broker по Уди)
elements
initial event
broker
processing event
processor/consumer
problems
data loss
ordering
Space-based
Плохо скалируется обычное решение
хорошее scalability и elasticity
Данные лежат в локальных кешах
Parts
Processing Unit
Messaging Grid
Nginx, for example
Data Grid
Replicated cache
Processing Grid
Optional
Deployment Manager
Data Pumps
Data Writer
Data Reader
Collisions
Cloud + On-Prem
Cache
Replicated
Distributed
Orchestration-Driven SOA
ESB
Taxonomy
Бизнес-сервисы
Enterprise сервисы
Сервисы приложения
Инфраструктурные сервисы
Движок оркестрации
Message Flow
Microservices
Fowler inspired (в отличие от других стилей)
Вдохновлены DDD
Bounded context != Domain
Сейчас говорят, что по Bounded Context делить неверно, может получиться слишком крупно
Как делить
Distributed транзакции - антипаттерн
Но если запретить совсем - будет монолит
Есть подход делить по аггрегатам
Duplication over coupling
Microservice не всегда должен быть маленький
Не должно быть сложной хореографии
Избегать Enitty trap (тупого CRUD)
Отличие SOA
Нет общей БД
Нет шины
service mesh
их может быть несколько
содержит общие вещи: мониторинг общих вещей, health check
sidecar
берёт на себя маршрутизацию запросов к другим сервисам
и базе и прочему
Service discovery
нужен для elasticity
недостаточно для elasticity
Microfrontends
Communication
Protocol aware
Heterogeneous
Interoperability
Transactions/sagas
Pending state
Undo/redo
Domain-centric
Выбор архитектурного стиля
Fashion
Изменения в экосистеме
Новые возможности
Мир вокруг ускоряется,
Изменения в предметной области
Технологии меняются
Внешние факторы
Наблюдения в прошлом
Критерии
Предметная область
Data architecture
Внешние факторы.
Команды-процессы
Изоморфизм домена и архитектуры
Вопросы
Монолит или распределенное
Где должны жить данные
Синхронно или асинхронно?
Техники и софтскиллы
Архитектурные решения
АНти-паттерны
Оттягивать решения
Last Responsible Moment
Аналитический паралич
Постоянное взаимодействие с девтим
День сурка
Бесконечные челленджи решений
Email-Driven Architecture
Архитектурно значимое
Структура
Нефункциональные характеристики
Зависимости
Интерфейсы
Техники конструирования
ADR
RFC
Асинхронно
Анализ рисков
Матрица рисков
Вероятность
Импакт
Оценка рисков: характериски x компоненты
Тренды
Риск-шторминг
Идентификация — независимо
Консенсус — коллективно
По характеристикам
Решения
Архитекторы, разработчики и техлиды
Диаграмминг и презентинг
Диаграмминг
Инструменты
привязанность к артефакту
UML это сложно
Презентинг
Эффективные команды
Границы команды
Контрол Фрик
Бумажный архитектор
Эффективный архитектор
Эластичное лидерство
Знакомство с командой
Размер команды
Общий опыт
Сложность проекта
Длительность проекта
Предупреждающие знаки
Плохие процессы
Феномен множественного невежества
Коллективная безответственность
Чеклисты
Code completion
Testing
Релиз
Guidance
Special purpose – Developer approval
General purpose – Architect approval
Framework – Architect decision
Лидерство и навыки переговоров
Переговоры
Бизнес
Базворды и фразы
Про деньги и время в последнюю очередь
Архитекторы
Демонстрация убивает дискуссию
Не кипятись
Разработчики
Предоставляйте объяснения
Позвольте сделать свое
Лидерство
4С
communication
collaboration
clarity
conciseness
будь прагматиком но и визионером
lead by example
Работа с командой >> проведения митингов
Карьерный путь
Правило 20 минут
Персональный радар