Слоистая архитектура, часть 2

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

Получилось так, что архитектура МСа повлияла на архитектуру системы. Исходно в системе имела место ошибка проектирования, при которой произошло перемешивание слоев на всех уровнях. Требовалось выработать новый подход, чтобы наш BFF был поддерживаемым. К какой модели мы пришли (картинка ниже, вторая)?

view-api — это API, отвечающая за агрегацию доменных данных и вывод необходимой информации на экран клиенту. Требования к view-api предъявляются следующие:

- все эндпоинты view-api доступны только с фронтов, т.е. вызывать их из других API нельзя
- данные для отображения на экране, которые не приходят из core-api, должны прописываться в конфигурации view-api (текст, цвета кнопок, фона и др.)
- из view-api нельзя обращаться напрямую в back-системы

core-api — API, отвечающая за получение и обработку доменных данных с возможностью переиспользования. Требования к core-api предъявляются следующие:

- все ручки core-api недоступны с фронтов
- core-api ничего не знают про данные для отображения на экране (текст, цвета кнопок и фона), только если не проксируют эти данные с back-системы
- в идеале обращений между core-api тоже быть не должно

По результатам анализа системы мы пришли к строгой (обращение между узлами одного слоя или строго одного нижележащего слоя) многослойной архитектуре на уровне взаимодействия сервисов в системе. Теперь каждый сервис отвечает либо за работу с доменом, либо за UI. Мы развязали эти независимые модули/слои, которые ранее были скреплены, чтобы добиться лучшего повторного использования (особенно доменных сервисов). За счет чего достигается строгость? Фронты теперь могут обращаться только к view-api, view-api — только к core-api, а core-api — только к back-системам и друг к другу.

Кто готов посмотреть битву 20$ / month ChatGPT 4 против Completely Free Llama-3?

Попробуем отрефакторить один и тот же метод на языке Kotlin с помощью двух этих моделей здесь.

Рефакторинг. Выделение метода, часть 1

Кажется, все знают, что функции/методы нужно делать короче. Вот как восторгается Роберт Мартин программе, написанной с помощью лаконичных функций:
… каждая функция в программе … занимала всего две, три или четыре строки. Все функции были предельно очевидными. Каждая функция излагала свою историю, и каждая история естественным образом подводила вас к началу следующей истории. Вот какими короткими должны быть функции!

Давайте разберем этот абзац, чтобы понять, как написать программу, которая порадовала бы Роберта Мартина. В первую очередь — это следовать SRP, однако не нужно ударяться в крайности, начиная делить код на множество микроскопических функций. Важно, чтобы те операции, которые вы выносите в функцию, находились на одном и том же уровне абстракции и являлись семантически независимыми (по отношению к остальному коду) и значимыми. Именно в таком случае функции будут представлять из себя строительные блоки, из которых может быть построена поддерживаемая программа. А дальше все просто: будучи носителями одной ответственности/семантики таким функциям несложно будет дать ясное и точное имя.

Рефакторинг. Выделение метода, часть 2

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

Что еще можно привести в качестве примеров? Конечно, использование сквозной функциональности:

- поэтапные логирование и аудит;
- замеры производительности отдельных участков кода и сбор метрик;
- и т.д.

Вот, например, поток аудита переплетается с бизнес-функциональностью подтверждения оффера:


suspend fun confirmOffer(...) {
...
try {
auditService.updateConfirmationStatus(auditReference, OperationStatus.PROGRESS)
offerService.confirmOffer(...)
auditService.updateConfirmationStatus(auditReference, OperationStatus.SUCCESS)
...
} catch (e: Exception) {
...
auditService.updateConfirmationStatus(auditReference, OperationStatus.FAIL)
...
}

Этот код можно было бы также оформить в виде конечного автомата, однако такое решение кажется здесь избыточным из-за малого числа состояний. Еще одним вариантом разделения двух несвязанных семантик в данном примере может быть применение техник АОП, которые однако не славятся простотой чтения и поддержки.

Что если в препарируемом методе нет автономных потоков вычислений, но и выделение новых методов кажется невозможным? Вероятно, в таком случае мы имеем дело с плохо написанным, запутанным кодом, который требует предварительной подготовки с использованием других техник рефакторинга.

Если обобщить, то у меня получилась следующая схема.

Предлагаю на примере Apache Kafka рассмотреть, какие есть подводные камни при сборе и использовании метрик. Не пугайтесь, если вы не знакомы с Kafka — эти идеи могут всплыть при мониторинге абсолютно любой системы.

Обзор DevSecOps, часть 1

Продолжаем тему Security при разработке приложений. На этой неделе проходил обучение по теме безопасной разработки ПО. Хочу поделиться с вами некоторой выжимкой.

Так полюбившиеся бизнесу гибкие методологии разработки (на основе Agile-манифеста) сильно повлияли на процессы разработки ПО в целом и на подход к информационной безопасности в частности. Как это выражается? Мы не сможем планомерно отдавать “безопасные” релизы, если будем следовать моделям “предыдущих поколений”, например Waterfall. Так появился Манифест Agile Security (Agile Security Manifesto). Его приоритеты естественным образом вытекают из принципов модели Agile:

- опора на разработчиков и тестировщиков, а не на специалистов безопасности
- проверка на безопасность в процессе, а не после завершения рабочего цикла
- безопасная реализация функциональности, а не добавление функций безопасности
- снижение рисков, а не поиск уязвимостей

Тут стоит отметить, что мы не упраздняем позицию “безопасник” в нашей структуре, а пытаемся с самого начала делать защищенный продукт за счет интеграции элементов Application Security (Sec) во все фазы цикла Development & Operations (DevOps).

Обзор DevSecOps, часть 2

Обратимся к графическому представлению DevSecOps и кратко пробежимся по предложенным методам.

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

Для проверки на наличие известных уязвимостей и анализа лицензионной чистоты подключаемых компонентов используют:
- на этапе дизайна — OSA (Open-Source Analysis)
- на этапе сборки — SCA (Software Composition Analysis)

Пример опасных уязвимостей, которые может выявить инструмент SCA:
- log4shell – критическая уязвимость в библиотеке log4j, позволяющая запускать неавторизованный удалённый код
- spring4shell – критическая уязвимость во фреймворке Spring, которая позволяет запускать произвольный код на сервере (RCE)

Инструментальные средства DAST анализируют приложения без доступа к их исходному коду, то есть методом «черного ящика». В отличие от SAST, менее привязан к языку программирования, на котором написано приложение, а также позволяет проверить влияние окружения, нюансов развернутой БД, сервера и прочих деталей системы. Конечно, вручную придется разбирать большое число ложных срабатываний.

Более распространенным термином для AppSec.Hub является ASOC (Application Security Orchestration & Correlation). ASOC-платформа обеспечивает оркестрацию проверок и работу с их результатами на всем протяжении жизненного цикла ПО.

Для полноты картины отмечу, что для анализа уровня безопасности мобильных программ используется специальный набор практик и методов тестирования – MAST (Mobile Application Security Testing).

В блоке BCA есть упоминание Container Analysis, который совместно с BAST в случае оркестрации контейнеризированных приложений образуют Container Security (также встречается термин SecOps) — это непрерывный процесс и комплексное мероприятие по обеспечению безопасности контейнеризированных приложений на всех этапах их жизненного цикла, а также платформ и систем, сопровождающих программные продукты. Процесс частично включает в себя практики SAST, SCA, DAST, Security Compliance и Observability. На данный момент основной тулсет составляют решения классов:

IaC scanner — сканирование файлов конфигураций бизнес — и/или инфраструктурных сервисов. Например, docker file, yaml-манифесты, ansible роли и т.д. Чаще всего также имеет функциональность поиска cve используемых компонент и небезопасного хранения секретов

Policy Engine/Admission Controller — контроллер и sec gate для ресурсов при деплое и в runtime микросервисов. Позволяет определять несоответствие спецификациям ИБ, блокировать поставки, изменять конфигурации или создавать дополнительные ресурсы

CSP (Container Security Platform) — обсервабилити решение с прицелом на ИБ функции

LSM — Linux Security Modules а также eBPF-based Security Observability and Runtime Enforcement. Данный класс инструментов направлен на ограничение процессов совершать определенные syscall

Наконец WAF — это аппаратное устройство или программное обеспечение, которое анализирует и фильтрует весь входящий и исходящий HTTP(S)-трафик.

Конечно, все это сверху должно быть приправлено пентестами и программой Bug Bounty для, действительно, комплексной проверки выстроенных мер защиты.

Варианты расширения функциональности классов и их влияние на модель данных в Kotlin [1/2]

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

data class Card(val id: String, ...)

Кое-где нам нужно получать приоритет (абсолютный вес) конкретного экземпляра для последующей сортировки и фильтрации.

Какие есть варианты реализации?

1️⃣ Наивный вариант — добавляем в исходный класс новое поле priority

Выглядит удобно: при вызове конструктора однократно выполняются вычисление и присваивание приоритета, после чего в программе это поле переиспользуем. В глаза бросаются сразу два ограничения:

❌ решение технически нереализуемо для закрытых для изменений third-party библиотек
❌ смешиваем технические и доменные поля в одном классе

Даже если мы имеем возможность модифицировать класс Card, то внесение в него нового поля, оторванного от домена, не пойдет на пользу модели данных. Стоит ли говорит о том, что глобальное расширение библиотечного класса усложнит аналитику и тестирование коллегам за пределами нашего сервиса. Также отметим, что приоритет карты даже в рамках одного сервиса нужен не везде.

2️⃣ Используем наследование или паттерн Декоратор (Decorator)

Если библиотечный класс помечен как open, то мы можем использовать наследование, иначе — декоратор. Какие здесь могут быть ограничения? Если область применения вновь созданных классов носит локальный характер, то мы получим колоссальный объем избыточного кода.

✅ подходит для расширения даже third-party библиотек
❗️для решения локальных задач создание новых классов может быть нецелесообразно

С учетом наших вводных создание наследника или декоратора класса Card выглядит неуместным.

Варианты расширения функциональности классов и их влияние на модель данных в Kotlin [2/2]

3️⃣ Используем функции расширения

Kotlin предоставляет возможность расширять класс или интерфейс новой функциональностью без необходимости наследования от класса или использования шаблонов проектирования, таких как Decorator. Это делается с помощью специальных объявлений, называемых функциями расширения (extension functions):

package edu.some

object CardPriority {
    private val priorityMap = WeakHashMap<Card, Int>()

    fun Card.setPriority(priority: Int) {
        priorityMap[this] = priority
    }

    fun Card.getPriority(): Int? {
        return priorityMap[this]
    }
}

Такие функции можно вызывать обычным способом, как если бы они были методами исходного класса, однако все же потребуется их импортировать явно:

package edu.other

import edu.some.CardPriority.getPriority
import edu.some.CardPriority.setPriority

fun main() {
    card.setPriority(2)
    println("Card priority is ${card.getPriority()}")
}

✅ подходит для расширения даже third-party библиотек
✅ минимальное количество нового кода, который не выходит за пределы сервиса
⚠️ доступ к методам, расширяющим исходную модель, ограничен только необходимостью явного импорта
❗️потребовалось введение внешнего хранилища

Несмотря на то, что мы ввели внешнее хранилище, мы оказываем незначительное влияние на исходную модель данных. Можно модифицировать этот код так, чтобы вызовы setPriority и getPriority можно было делать только в явно ограниченном контексте. Для этого можно использовать вложенные классы или функции с приемом контекста. Вот пример использования вложенного класса:

package edu.some

object CardPriority {
    private val priorityMap = WeakHashMap<Card, Int>()

    class Context {
        fun Card.setPriority(priority: Int) {
            priorityMap[this] = priority
        }

        fun Card.getPriority(): Int? {
            return priorityMap[this]
        }
    }

    fun withCardPriorityContext(action: Context.() -> Unit) {
        Context().action()
    }
}

Вот как будет выглядеть вызов:

package edu.other

import edu.some.CardPriority.withCardPriorityContext

fun main() {
    ...
    withCardPriorityContext {
        card.setPriority(2)
        println("Card ${card.id} is ${card.getPriority()} priority")
    }

    // cледующие вызовы не скомпилируются, так как находятся вне контекста
    // card.setPriority(2)
    // println("Card priority is ${card.getPriority()}")
}

Пример с использованием функции, которая принимает контекст можно посмотреть здесь.

В чем отличие от исходного варианта?
✅ доступ к методам, расширяющим исходную модель, ограничен в коде явно
⚠️ требуется вызов конструктора на каждый возов логики

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

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

Как вам результат? Хотел написать пост, когда счетчик достигнет 20, но в последнее время отдавал приоритет менти, которые приходят на повторные консультации. Самый крутой результат из этих ребят — джавист с 1 годом коммерческого опыта повысил ЗП со 100 до 265 т.р. на руки, устроившись в финтех на позицию middle. Если вы до сих пор топчитесь на месте по своим карьерным целям, то рекомендую все же заскочить ко мне на бесплатную часовую консультацию. Многим этого более чем достаточно, чтобы сдвинуться с мертвой точки, а иногда и покорить очередную неприступную вершину.