Архитектура программного обеспечения

Ради удобства разработки программисты часто пишут плохой код, что в конечном итоге приводит к тому, что мы традиционно называем лашпшекодом, спагетти или говнокодом. Это приводит к функциональному параличу в какой-то момент времени, когда стоимость создания заново дешевле, чем исправление существующего кода. Некоторые из характеристик таковы

Как правило, никогда не бывает одного подходящего для всех стиля. Проектирование архитектуры для решения проблемы зависят от контекста, и у каждого стиля есть свой компромисс. Ниже приведены некоторые из наиболее часто используемых архитектурных стилей, которые обычно сочетаются друг с другом. Какая комбинация лучше всего подходит для вашего приложения, лучше всего известно именно вам.

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

Домен здесь представляет ментальную модель пользователей системы. Это наиболее стабильная часть архитектуры, которая редко меняется. За ним следует уровень приложений, который встраивает варианты использования. Эти варианты использования определяют все остальное.

Определены 2 такие модели предметной области: шестиугольная и луковичная модели. Суть в том, что каждый из внешних слоев зависит от внутреннего слоя, в то время как внутренний слой не будет знать о внешнем слое.

Плюсы

Минусы

Как только граница домена определена, следующим идет уровень приложения. Прикладной уровень становится надежным благодаря применению нижеприведенных SOLID принципов.

Абстракции (ЧТО?) — Приложение должно быть построено таким образом, чтобы оно могло содержать бизнес-логику с использованием абстракций. Он должен сосредоточиться на том, что(?) он хочет делать.

Сегрегация(КАК?) — это сделано, аспект деталей реализации можно подключить с помощью инъекции зависимостей(DI). DI применяется не только для внедрения бизнес-логики с использованием различных шаблонов проектирования, но и конкретно применяется при внедрении элементов инфраструктуры, таких как базы данных, кэш, серверы уведомлений, внешние веб-службы и т.д.

Интерфейсы/Контракты — Такой подход автоматически создает многоуровневую архитектуру с четкими интерфейсами для каждого внешнего элемента. Разделение ответственности в сочетании с тем, что каждый слой владеет одной-единственной ответственностью, уменьшает сцепление. Это, в свою очередь, помогает легко тестируемому коду, который также может быть протестирован с помощью моков (mocks).

Опять же, уровень приложений не зависит ни от каких других деталей реализации и имеет только знания о доменном уровне, от которого он зависит.

В прежние времена у нас была единая модель единого домена для представления клиента или продукта в контексте продаж и в контексте поддержки. Например, контакт службы поддержки и клиент отдела продаж были смоделированы как единая модель клиента. По мере того как пространство решения становится больше, чтобы иметь все больше и больше доменов, мы добавляем больше атрибутов, свойств и правил проверки, которые применяются только к одному домену, но которые неверны для другого домена, что приводит к ненужным затратам на сложность такого унифицированного кода.

Ограниченный контекст —Это признание определенной контекстуальной области, в которой конкретная терминология модели предметной области является допустимой и имеет смысл.

В новой модели вам не нужно помещать “Контакт” в “Клиента ” в домене поддержки. Но вместо этого используйте правильную терминологию “Контакт” в области поддержки. Когда вы хотите поговорить с доменом продаж, вы преобразуете “Контакт” в объект “Клиент”, используя четко определенные интерфейсы. Это также приводит к высокой функциональной когезии и уменьшает сцепление между различными областями.

Определены микросервисы — они разделяют единый монолит на подсистемы, которые несут единую ответственность как услуга. Они взаимодействуют друг с другом с помощью четко определенных интерфейсов. Они имеют автономное развертывание, имеют собственную независимую базу данных и службы резервного копирования. Каждый микросервис самостоятельно выбирает технологический стек, инструменты, методы, которые наилучшим образом подходят ему. Они масштабируются независимо друг от друга. Команды относительно невелики. Возможно, одна команда заботится об одном или нескольких микросервисах. Каждой команде просто нужно знать предметную область микросервиса, за который они отвечают, а не все в монолите.

Минусы

Микросервисы теперь могут взаимодействовать друг с другом, используя механизм запроса/ответа, такой как JSON, через вызовы REST или используя управляемую событиями архитектуру с посредником сообщений. Современная архитектура предпочитает EDA, поскольку она позволяет службам более гибко реагировать, сокращать задержки, обеспечивать надежное, отказоустойчивое, гарантированное обслуживание и позволяет лучше масштабироваться.

В EDA есть 3 участника, а именно производитель, который создает запускающее событие, посредник сообщений, который надежно передает сообщение, и потребитель, который может подписаться на конкретное или на все события. Это приводит к “реактивному программированию”, которое реагирует на событие(триггер), поступающее из потока данных, что приводит к более быстрому времени отклика и, следовательно, к низкой задержке.

Для микросервисов, которым требуются ACID свойства транзакций между микросервисами с использованием возможной согласованности, вместо EDA используется шаблон SAGA, в котором используется явный механизм отката для обработки условий ошибок для отката изменений. Это, однако, усложняет конструкцию, поэтому следует использовать с осторожностью.

Появление микросервиса и EDA также породило шаблон CQRS. Команда-это то, что изменяет состояние базового объекта, и запрос не изменяет объект, а просто возвращает запрошенное подмножество объектов.

Чем это полезно? Несколько примеров