Код ;Категория;Описание требования / рекомендации;Предпосылки и мотивация;Рекомендации по реализации

ARC-GEN-01;01-Общие архитектурные требования;При проектировании приложений следует использовать ПО, идентифицированное в <span class="keyword" title="Технологический стек">Тех-стэке</span> Консорциума;Простота учёта известных ограничений по лицензиям и поддержке<br />Использование знаний от практики применения технологий участников Консорциума<br />Снижение затрат поставщиков и потребителей ПО за счёт использования общих технологий;см. TechStack ARC-GEN-02;01-Общие архитектурные требования;При проектировании сервисов следует руководствоваться общепринятыми в индустрии разработки ПО архитектурными принципами и <span class="keyword" title="Паттерн">паттернами</span>;Следование данным принципам повысит независимость архитектурных компонентов и устойчивость компонентов платформы и продуктов на ней к изменениям<br />Спроектированные на основе этих принципов сервисы проще поддерживать и дорабатывать;Ориентированными на логическую организацию ПО, такие как: <span class="keyword" title="Подход к проектированию ПО, который фокусируется на модели предметной области и её логике">Domain Driven Design</span> (DDD), <span class="keyword" title="Пять принципов объектно-ориентированного программирования">SOLID</span>, <span class="keyword" title="Шаблоны проектирования ПО 'Общие шаблоны распределения ответственности'">GRASP</span><br />ориентированные на технологическую организацию, такие как <span class="keyword" title="Методология разработки SaaS-приложений">12 factor app</span><br />или комплексные стили, их объединяющие: <span class="keyword" title="Архитектурный стиль, при котором приложение состоит из небольших, слабо связанных сервисов">Microservices</span> ARC-LGC-01;02-Логика приложения, модель предметной области, контракты;Явно задавайте <span class="keyword" title="описание API сервиса / приложение на формальном языке, которое может включать спецификацию поведения, форматы запросов/ответов и технические детали для интеграции">контракты</span> информационных сервисов. Четко и тщательно прорабатывайте контракт <span class="keyword" title="Набор правил, протоколов, функций и процедур, которые позволяют различным программным приложениям или компонентам взаимодействовать друг с другом">API</span><br />Отталкивайтесь от контракта при разработке логики приложения;Упрощение интеграций между системами; ARC-LGC-02;02-Логика приложения, модель предметной области, контракты;Проектируете единую схему данных от модели предметной области для использования в контрактах сервисов (паттерн "Каноническая схема");Упрощение интеграций между системами; ARC-LGC-03;02-Логика приложения, модель предметной области, контракты;Поддерживайте стабильность контрактов интерфейсов<br />(Приложение должно предсказуемо отвечать на запросы сторонних систем, даже в процессе разработке);;См. секцию INT ARC-LGC-04;02-Логика приложения, модель предметной области, контракты;При проектировании контрактов сервисов рекомендовано добавлять публикацию событий изменений основных сущностей объектной доменной модели;упрощение аудита<br />поддержка паттерна интеграции с обработкой изменения состояний;Ссылка на другие части стандарта ARC-LGC-05;02-Логика приложения, модель предметной области, контракты;Определяйте для приложений метрики для мониторинга бизнес-активностей;;Объеденить с предыдущим<br />Также сомнительно использования технического дашборда мониторинга для бизнес-метрик (что не исключает создание дашборда на основе Grafana для бизнес метрик) ARC-STE-01;03-Хранение состояния (state);Проектируйте приложение как один или несколько процессов, не сохраняющих внутреннее состояние<br />Данные приложения (состояние) должны хранится в сторонней службе, обычно, в базе данных и/или <span class="keyword" title="Технология хранения данных объектов. Разработана компанией Amazon Web Services (AWS) в 2006 году">S3</span> объектном хранилище;Возможность лёгкого масштабирования и обеспечения отказоустойчивости<br />Отсутствие привязки к данным (stateless)позволит горизонтально масштабировать сервисы в зависимости от наблюдаемых метрик нагрузки, тем самым обеспечивая заложенные в архитектуру платформы и разрабатываемых на её основе продуктов показатели производительности и потребления ресурсов<br />Исключение хранения артефактов сервисов в неструктурированном и разрозненном виде (что осложнило бы к ним доступ, потребуется написания уникальных адаптеров доступа и процедур резервного копирования);См. рекомендуемые хранилища в TechStack<br />Осуществлять развертывание хранилищ данных отдельно от сервисов, в том числе на основе другой инфраструктурной платформы. Например: сервисы на k8s, а БД на виртуальных или реальных серверах. ARC-STE-02;03-Хранение состояния (state);Проектируйте и реализуйте приложения, чтобы их процессы могли быть запущены и остановлены в любой момент средой исполнения ("утилизируемость" процессов). Поддерживайте плавный останов;Максимизация надёжности и восстанавливаемости приложения<br />Обеспечение масштабируемости;В дополнение к хранению состояния в специализированных службах, в разрабатываемом приложении, также должны быть реализованы процедуры быстрого запуска и корректного (плавного) останова и завершения работы, и "пробы", позволяющие среде исполнения понимать текущее состояние готовности процесса приложения. См. PRD ARC-STE-03;03-Хранение состояния (state);Приложение должно быть способно масштабироваться горизонтально, т.е. увеличением количества реплик, а не расширением доступных ресурсов. Рекомендовано использовать среду исполнению, поддерживающую горизонтальное автоматическое масштабирование;Возможность быстрого ответа на возрастающие потребности<br />Оптимизация использования вычислительных ресурсов; ARC-DEP-01;04-Зависимости (dependencies);Явно объявляйте и изолируйте все зависимости приложения от стороннего ПО: как статические зависимости (контроллируемые при интеграции), так и зависимости времени исполнения в сопровождающей документации;; ARC-DEP-02;04-Зависимости (dependencies);При проектировании закладывайте механизмы слабой связности как сервисам смежных приложений, так и техническим службам (базы данных,..);Данный подход обеспечивает принципы модульности систем и слабой связности, где связи между системами выносятся в параметры конфигурации, а не зашиваются жестко в код при сборке;Использование соответствующих паттернов проектирования: интерфейс, сервис имён ARC-DEP-03;04-Зависимости (dependencies);При проектировании закладывайте достаточные механизмы обработки ошибок и недоступности со стороны как сервисных смежных приложений, так и технических служб (базы данных,..);; ARC-DEP-04;04-Зависимости (dependencies);Избегайте в проектирования приложений, использующих файловые обменники (NFS) для хранения или обмена данными между собой, в пользу блочного хранилища системы виртуализации/контейнерной среды и/или объектного S3 хранилища (и механизмы коммуникацию через API или MQ);Это также способ обеспечить принципы слабой связности между системами и сервисами на уровне обмена данными (коммуникациях); ARC-INFR-01;05-Инфраструктура (infrastructure);Рекомендуется использовать PaaS/IaaS сервисы доступные в ландшафте организации (доступные для установки в рамках технической и ИБ политики);Упрощение реализации требований по доступности и производительности самого приложения<br />Упрощение поддержки компонентов решений;Требует высокой степени зрелости инфраструктурной платформы предприятия: требуется и интеграция с cloud-провайдерами или собственное private-cloud ARC-INFR-02;05-Инфраструктура (infrastructure);Проектируйте приложения с учётом требований и особенностей распределенных инфраструктур компаний (ЦОДы, локальные площадки) с учётом характеристик каналов связи между ними с особым вниманием к факторам ненадёжности (узкие, ненадёжные каналы, экранирование помещений и проч.);Слой инфры не должен быть зависим от специфики конкретной организации. Не стоит ожидать 100% надежности от инфраструктур.; ARC-INFR-03;05-Инфраструктура (infrastructure);Для приложений класса высокой и средней доступности (время допустимого RTO определяется case by case) архитектура сервисов должна обеспечивать одновременную работу компонентов сервисов в двух и более зонах доступности (двух и более ЦОД) в режиме Active/Active, либо в режиме Active/Passive;Обеспечение непрерывности критичных для бизнеса процессов. Данную особенность нужно закладывать в архитектуре, т.к. реализация на более поздних этапах ведет к высоким трудозатрат на адаптацию решений;Использование практик обеспечения горизонтального масштабирования систем и компонентов. Обеспечение независимости работы на уровне инфраструктуры или работа в cloud ARC-INFR-04;05-Инфраструктура (infrastructure);При проектировании схем развёртывания приложения следует учитывать разделение на зоны принятые в инфраструктуре. Как правила сетевые обращения инициируют сегменты с большим доверием к сегментам с низким доверием, но не наоборот.;Обеспечение сетевой безопасности;Учитывать при проектировании ограничения по однонаправленным сетевым подключениям. Имитировать двусторонний обмен можно с помощью брокеров очередей или других средств на основе firewall ARC-INFR-05;05-Инфраструктура (infrastructure);Архитектура сервисов должна предусматривать использование штатных для организации механизмов резервного копирования и механизмов аварийного восстановления;Для обеспечения непрерывности работоспособности ПО в рамках эксплуатации<br />Упрощение внедрения ПО в эксплуатацию;Индивидуально для каждой компании в зависимости от используемых средств. ARC-ENV-01;06-Окружение (environment);Разрабатываемые сервисы должны поддерживать развертывание в средах (окружениях) различного назначения: активной разработки, тестирования, приёмочного и интеграционного тестирования, промышленной эксплуатации;Для обеспечения качества и безопасности и разделения разных этапов тестирования между собой;Как вариант: разработки (DEV), среды тестирования (TEST), препрод/стейдж (STAGE), промышленной эксплуатации (PROD) ARC-ENV-02;06-Окружение (environment);Сохраняйте конфигурацию в среде выполнения: конфигурация не должна находиться в коде. Кодовая база не должна изменяться для разворачивания на разных окружениях и переноситься без пересборки артефактов;Для обеспечения качества и безопасности необходимо исключить возможность внесения изменений при переносе образов сборки между средами;Использование практики "единая сборка"/ "golden image" ARC-ENV-03;06-Окружение (environment);Рекомендуется соблюдать практику принципиальной идентичности между средами, через которые проходит ПО в ходе разработки;Это обеспечивает преимущества непрерывного развёртывания благодаря минимизации различий между разработкой и работой приложения, а также быстро проверять поведение создаваемого ПО в похожей среде;Использование практики CD и идентичных параметризованных скриптов развертывания во всех средах. В средах должны соблюдаться одинаковые подходы по работе с сетью, доступами, обращениями к системам и др. Отличия могут заключаться в используемых данных или инфраструктурных мощностях