JavaOpt: Паттерны

Основные

SOLID
S - Single Responsibility Principle - интерфейсы, классы и методы должны выполнять только 1 задачу и делать это хорошо!
O - Open-Close Principle - методы, классы и интерфейсы должны быть открыты для расширения, но не для изменения. В особенности это касается публичных библиотек с множеством внешних зависимостей
L - Liskov Substitution Principle - принцип в основе которого лежит заменяемость родительского класса любым его наследником. Иными словами, там где возможно, следует использовать максимально базовую абстракцию
I - Interface Segregfation Principle - принцип согласно которому интерфейсы следует разбивать на множество мелких, с более узконаправленными функциями. Реализация будет зависеть уже от класса.
D - Dependency Invertion Principle - классы не должны зависеть от конкретных реализаций, только от абстракций. Так, вставка (передача) в класс зависимостей должна представлять собой только абстракции
DRY - Don’t Repeat Yourself - следует избегать дублирования кода
KISS - Keep It Simple, Stupid - написание кода должно быть максимально просты, чтобы понимание было интуитивным
TDD - Test-Driven Development - принцип разработки, при котором наложение тестов идет несколько опережающими темпами относительно реализации задачи.

12 Factor app

Codebase. В VCS должно лежать все что так или иначе связано с приложением (чтобы оно заработало). К нему должны иметь доступ все заинтересованные лица + CI/CD
Depencencies. Хранение артефактов в VCS запрещено. В контроле версий должно лежать только уникальная и необходимая для проекта база
Configurations. Параметры приложения следует выносить из кода в переменные окружения или конфигурационные файлы
Backing Services. Внешние для приложения сервисы должны быть отделены от него и максимально абстрагированы. Поддержку предпочтительнее переносить на другую команду (речь про БД, почтовые сервисы, стриминговые сервисы и прочие)
Build, Release, Run. Принцип, согласно которому приложение каждый раз собирается, поставляется и запускается “с нуля”.
Process. Процессы в рамках приложения должны быть атомарны с наименьшим количеством взаимозависимостей. Например, с 1 внешним ресурсом работает 1 сервис и он же выполняет все необходимые действия, предоставляя сервис
Port Binding. Каждому сервису выделяется отдельный сетевой порт, который дополнительно идентифицирует сервис
Concurrency. Сервис в рамках приложения должен быть легко масштабируемым как в сторону увеличения, так и в сторону уменьшения
Disposability. Приложение/сервис сам должен следить за корректностью старта. Если он получил статус успешно запущенного - это значит лишь одно - он гарантированно работает на 100%
Dev/Prod Parity. Окружение/контура работы (dev и prod) должны быть идентичными. Допускаются минорные различия и различия в масштабировании
Logs. Логи должны быть максимально разбиты и сгруппированы по целевым группам их читателей (например, только логи с ошибками, только HTTP запрос/ответ, только работа с БД и т.д.)
Admin Process. Ключевые участки работы всего приложения носят максимальный приоритет (даже если зависят от внешних ресурсов и сервисов). Их всегда следует рассматривать как ключевой элемент системы!