База знаний Антона Сидорова

База знаний по аналитике, ИТ архитектуре, API. Документирование. Тесты инструментов.

---

Project maintained by daemon110282 Hosted on GitHub Pages — Theme by mattgraham

Архитектура

• Архитектура
  • Зачем
  • Задачи IT-архитектора
  • Законы архитектуры
  • Процесс
  • Элементы архитектуры

Зачем

• Архитектура :
  • структура системы в определенном Стиле архитектуры
  • включающая все
    • компоненты ПО из которых она состоит
    • оборудование и людей
  • устанавливает границы между разными компонентами приложения и их ответственностями
  • обеспечивающая необходимые Качества архитектуры (архитектурные характеристики)
  • исходя из НФТ
  • предоставляющая интерфейсы компонентов
    • Требования для интерфейса внешнего устройства API ~ external interface requirement —
      • описание интерфейса между системой ПО и пользователем
      • другой системой ПО - интеграции
      • или оборудованием
  • взаимосвязи между этими компонентами и поведение компонентов, видимое другим компонентам (слои приложения)
  • построеной на технологической базе (тех стек) различных классов систем: APM, CDN, WAF, IAM, CIAM, SIEM, DWH, Report, Store, Mobile, BPMS и тп
  • совокупность правил, методов и Шаблонов Паттернов разработки приложений

Архитектор знает

• когда полезно использовать определенную технологию исходя из Критерией выбора решения, самое главное – когда этого не нужно делать
• какие есть риски
• общепринятые Reference Architecture
• Подходы к Документированию архитектуры

Задачи IT-архитектора

• Обеспечить баланс между стоимостью разработки и гибкостью решения для быстрого внедрения будущих требований
  • We design software to reduce its cost. The cost of software is ≈ the cost of changing the software
    • The cost of changing the software is ≈ the cost of the expensive changes (power laws and all that)
      • The cost of the expensive changes is generated by cascading changes — if I change this then I have to change that and that, and if I change that then
  • Coupling between elements of a design is this propensity for a change to propagate
  • So, design ≈ cost ≈ change ≈ big change ≈ coupling. Transitively, software design ≈ managing coupling
• Фиксировать и распространять знания
• Преодолевать разрыв между предметной областью и технической командой

Critical Skills:

• Анализирует бизнес-требования в рамках задач направления. Предлагает альтернативы.
• Разрабатывает и согласовывает архитектурное решение по задачам направления
• Проектирует компонентную, информационную, системную, техническую (деплой) архитектуру
  • Использует на практике архитектурные подходы (паттерны) проектирования (SOA, MSA, EDA, …)
  • Проводит декомпозицию вновь создаваемых решений, владеет подходом Domain Driven Design
  • Использует на практике профильные нотации описания архитектуры (например, C4).
  • Проектирует интеграцию систем. Определяет способы, протоколы, инструменты интеграции (очереди rabbit, kafka, ESB, ETL инструменты)
• Контролировать реализацию: заложить каркас системы и провести архитектурный надзор
• Понимает и иcпользует на практике требования информационной безопасности
• Разрабатывает нефункциональные требования
• Проеделяет техстек, компонентный состав решений. Знает языки и фреймворки, классы и экземпляры БД
• Архитектор декларирует общие концепции: аналитик, разработчик реализует их (пример шаблон API, ПЗ)
  • императивное программирование — как сделать. Пример: Купить овощи, замешать, сварить борщ
  • декларативное программирование — что сделать. Пример: Сделайте борщ.
    • декларативное программирование по-прежнему использует императивное программирование под капотом, поэтому невозможно писать только декларативный код

Other Skills:

• Применяет знания предметной области бизнеса
• Знает типовые концепты и ИТ-решения рынка бизнеса
• Владеет разными нотациями описания архитектуры
• Владеет и использует на практике стандарты и методологии гибкой разработки

Законы архитектуры

• Everything in software architecture is a trade-off. Любое решение является компромиссом.
  • Нет плохих решений - есть цели и контекст бизнеса (пример: сделать самолет военный, гражданский)
• Вопрос “почему” является важнее вопроса “как”
  • Библиотеки и фреймворки - детали реализации, которые должны быть скрыты.
• Закон Конвея — «Организации проектируют системы, которые копируют структуру коммуникаций в этой организации»

Процесс

Порядок (пирамида) проработки архитектуры решения:

• Функциональная (use case, ПЗ, БТ)
  • Выявить все функции, которые необходимо проанализировать при реализации бизнес задачи
• Информационная (модель данных, предметная область, сущность, связи)
  • Разложить все требуемые функции по правильным системам
• Анализ вариантов
  • Компромис бизнес проблем, целей и тех решения с учетом дальнейшего развития
  • Плюсы и минусы
  • Посчитать в деньгах, трудоемкости
• Прикладная (взаимодействия компонентов)
• Интеграционная (РИПВ)
  • Cпроектировать необходимые интеграции между системами и модулями, или взаимодействие с внешними системами
• Технологическая (инфраструктура, ИБ)
• Групповые ревью - подход коллективный архитектор

Элементы архитектуры

• Сервис — это единица прикладного поведения, заключает полный сценарий
  • Сервис может использовать другие сервисы как части своего сценария
• Система — иерархия сервисов, сгруппированных в домены
• Продукт — это совокупность сервисов, совместно реализующих некоторую ценность для конечного пользователя
  • Границы продукта отражают некоторую предметную область бизнеса
  • Продукты могут использовать общую платформ
• Платформа
  • Платформа является частным случаем продукта для внутренних пользователей
  • Платформы решают задачи обеспечения бизнес-процессов, используемых множеством продуктов
  • Платформа предоставляет набор повторно используемых сервисов
  • Платформа может стать самостоятельным продуктом