Предисловие

Критерии качества архитектуры ПО - Цель проектирования ПО и критерии качества архитектуры

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

Введение

Заставить ПО работать - очень простая задача, с ней справляются даже зеленые джуны. А вот сделать все правильно гораздо сложнее. Для этого нужны знания и навыки, до которых джуны еще не доросли. Для этого нужны мысли и озарения, на которые у разработчиков обычно нет времени. Для этого нужна такая дисциплина, которая многим из нас и не снилась. Но больше всего для этого нужна страсть к ремеслу программиста и неуёмное желание стать настоящим профессионалом.

Грязный код редко удается исправить впоследствии

Единственный способ развернуть тенденцию производительности труда к снижению, а затрат - к росту, - это перестать заблуждаться и принять на себя ответственность за бардак в коде.

Две ценности ПО - поведение и структура

Матрица Эйзенхауэра: архитектура - это важная, но никогда не срочная задача. Поведение же - всегда срочная, но редко очень важная задача. По приоритетам квадратов матрицы поведение попадает в 1 и 3 приоритеты, а архитектура - во второй. Проблема в том, что менеджеры не могут разделить поведение на приоритеты 1 и 3, и поэтому поднимают все поведение в квадрат 1.

Парадигмы программирования - Парадигмы программирования и их связь с архитектурой ПО

Принципы проектирования на уровне исходного кода (SOLID) - Принципы проектирования на уровне исходного кода (SOLID)

Принципы проектирования на уровне компонентов

Компонент ПО - Определение компонента ПО.

Решения о том, в каких компонентах размещать классы, обычно принимаются “на лету”, исходя только из текущего контекста, что пагубно влияет на архитектуру.

1. RREQ - Reuse/Release Equivalence Principle, принцип тождества релиза и переиспользования. The granule of reuse is the granule of release. Мы не можем переиспользовать компоненты до тех пор, пока они официально не релизятся и не получают номера релизов. Это отражает тот факт, что разработчики, использующие такой компонент, должны удостовериться в его совместимости с остальной системой, а также знать о выходе новых релизов и понимать, какие изменения внесены в очередную версию компонента. Из этого следует, что процесс релиза компонентов должен обеспечивать публикацию актуальных списков изменений.
2. CCP - Common Closure Principle, общий принцип закрытости. Объединяйте в компоненты классы, которые изменяются в одно и то же время по одним и тем же причинам. Соответственно, по разным компонентам нужно разносить классы, которые изменяются с разной скоростью и по разным причинам.
3. CRP - Common Reuse Principle, общий принцип переиспользования. Не принуждайте пользователей компонента зависеть от ненужных им вещей.
4. ADP - Acyclic Dependencies Principle, принцип ациклических зависимостей. Allow no cycles in the component dependency graph. Зависимости компонентов никогда не удаётся спроектировать заранее, эта структура постоянно эволюционирует по мере накопления знаний о системе.
5. SDP - Stable Dependencies Principle, принцип стабильных зависимостей. Depend in the direction of stability, см. Архитектура ПО - Stable Dependencies Principle.
6. SAP - Stable Abstractions Principle, принцип стабильных абстракций. A component should be as abstract as it is stable, см. Архитектура ПО - Stable Abstractions Principle.

Архитектура

Архитектура ПО как совокупность отложенных решений

Хорошая архитектура должна поддерживать:

1. Поведение системы (варианты использования, они направляют разработку системы Процесс разработки ПО управляется вариантами использования). Обеспечивается за счет изоляции бизнес-объектов и бизнес- правил в объектах Сущность (Entity). Такие объекты - это то, что “помогает заработать или сохранить деньги” для бизнеса; то, без чего бизнес не смог бы существовать. Варианты использования управляют сущностями, вызывают их поведение (см. https://habr.com/ru/company/exness/blog/496282/).
2. Эксплуатацию - это нефункциональные требования, изоляция компонентов, чтобы решение о “монолитности” / “микросервисности” можно было не принимать как можно дольше. #МартинРоберт рекомендует проводить разделение на компоненты до состояния, когда их можно выделить в изолированный микросервис, но оставить внутри монолита до тех пор, пока микросервис не станет насущной необходимостью.
3. Разработку. Упоминается закон Конвея Закон Конвея о том, что структура кода отражает организационную структуру компании.
4. Развертывание. Цель - мгновенное развертывание. Это достигается за счет грамотной изоляции компонентов и продуманности связей между ними, а также за счет функций мастер-компонентов (собирающих приложение целиком).

Software architects are the best programmers, and they continue to take programming tasks, while they also guide the rest of the team toward a design that maximizes productivity. Software architects may not write as much code as other programmers do, but they continue to engage in programming tasks. They do this because they cannot do their jobs properly if they are not experiencing the problems that they are creating for the rest of the programmers.

Сервисы, которые просто разделяют поведение приложения, - это всего лишь более “дорогие” вызовы функций. Они необязательно являются архитектурно значимыми.