Технічні науки

УДК 004.451.5+004.414.2

Жумік Владислав Миколайович

студент

Національного аерокосмічного університету

“Харківський авіаційний інститут”

Zhumik Vladyslav

Student of the

National Aerospace University “Kharkiv Aviation Institute” 

https://www.doi.org/10.25313/2524-2695-2025-12-05-37

ПОРІВНЯЛЬНИЙ АНАЛІЗ ДЕТЕРМІНОВАНИХ ТА ІМОВІРНІСНИХ МЕТОДІВ ВЕРИФІКАЦІЇ АРХІТЕКТУРНИХ ОБМЕЖЕНЬ У МІКРОСЕРВІСНИХ СИСТЕМАХ

COMPARATIVE ANALYSIS OF DETERMINISTIC AND PROBABILISTIC METHODS FOR VERIFYING ARCHITECTURAL CONSTRAINTS IN MICROSERVICE SYSTEMS

Анотація. У статті вирішено актуальне завдання автоматизації контролю архітектурної якості мікросервісних систем, спроєктованих за методологією Domain-Driven Design (DDD). Проведено порівняльний аналіз ефективності детермінованих та імовірнісних методів верифікації. На прикладі змодельованої системи електронної комерції з контрольованим набором дефектів виконано кількісну оцінку метрик точності та повноти для обох підходів. Експериментально підтверджено, що детерміновані методи забезпечують абсолютну точність при виявленні структурних порушень меж контекстів, але демонструють “семантичну сліпоту” щодо складних патернів DDD. Водночас імовірнісні методи показали високу ефективність у виявленні семантичних дефектів, таких як анемічна модель домену та протікання контексту, при допустимому рівні хибних спрацювань. На основі отриманих результатів обґрунтовано необхідність впровадження гібридної стратегії верифікації, де статичний аналіз виступає жорстким фільтром у CI/CD, а AI-інструменти виконують роль інтелектуального асистента архітектор.

Ключові слова: Domain-Driven Design, мікросервісна архітектура, архітектурна верифікація, статичний аналіз, імовірнісні методи.

Summary. The article addresses the challenge of automating architectural quality control in microservice systems designed using Domain-Driven Design methodology. A comparative analysis of the effectiveness of deterministic methods and probabilistic methods was conducted. Using a simulated e-commerce system with a controlled set of defects, a quantitative assessment of Precision and Recall metrics was performed for both approaches. The experiment confirmed that deterministic methods ensure absolute precision in detecting structural boundary violations but exhibit “semantic blindness” regarding complex DDD patterns. Conversely, probabilistic methods demonstrated high effectiveness in identifying semantic defects, such as anemic domain models and context leakage, with an acceptable level of false positives. Based on the results, the necessity of implementing a hybrid verification strategy is substantiated, where static analysis acts as a rigid gatekeeper in CI/CD pipelines, while AI tools serve as an intelligent architect’s assistant.

Key words: Domain-Driven Design, microservice architecture, architectural verification, static analysis, probabilistic methods.

Вступ. У сучасній інженерії програмного забезпечення перехід до мікросервісних архітектур та впровадження методології Domain-Driven Design (DDD) стали де-факто стандартом для розробки складних корпоративних систем. Ключовою перевагою таких підходів є можливість декомпозиції складної предметної області на ізольовані обмежені контексти, що дозволяє командам працювати автономно. Однак зі зростанням масштабу систем виникає явище “архітектурної ерозії”, коли фактична реалізація коду поступово відхиляється від закладених архітектурних моделей. У цьому контексті автоматизована верифікація архітектурних обмежень стає критично важливою складовою процесів безперервної інтеграції (CI/CD).

Традиційним підходом до вирішення цієї задачі є застосування детермінованих інструментів статичного аналізу, які перевіряють відповідність коду набору формалізованих правил. Ці інструменти, працюючи на рівні абстрактного синтаксичного дерева, забезпечують високу точність виявлення структурних порушень, таких як небажані циклічні залежності або порушення шаруватості архітектури. Проте, як свідчить практика, детерміновані методи демонструють обмежену ефективність при аналізі семантичних аспектів DDD — наприклад, перевірці коректності виділення агрегатів, дотриманні єдиної мови (Ubiquitous Language) або виявленні логічного дублювання бізнес-правил між мікросервісами.

З іншого боку, стрімкий розвиток методів штучного інтелекту, зокрема великих мовних моделей (LLM) та векторного представлення коду (Code Embeddings), відкриває нові можливості для імовірнісного аналізу архітектури. Такі підходи здатні оперувати семантичним контекстом, що дозволяє виявляти складні патерни та “архітектурні запахи”, недоступні для класичних лінтерів. Водночас їх застосування у промислових середовищах стримується проблемами стохастичної природи результатів та ризиками “галюцинацій”.

Незважаючи на активний розвиток обох напрямів, у науковій літературі бракує комплексних досліджень, що безпосередньо порівнювали б ефективність детермінованих та імовірнісних методів на специфічних задачах DDD.

Метою цієї статті є проведення порівняльного аналізу ефективності детермінованих та імовірнісних методів верифікації архітектурних обмежень. Дослідження спрямоване на кількісну оцінку метрик точності  та повноти обох підходів при виявленні типових структурних та семантичних порушень у мікросервісних системах. Отримані результати мають стати основою для обґрунтування доцільності створення гібридних систем архітектурного контролю.

Формалізація методів

 Детермінований підхід

В основі детермінованого підходу до архітектурного контролю лежить аксіоматичне припущення, що будь-яке архітектурне правило може бути зведене до набору булевих логічних умов, які перевіряються шляхом статичного аналізу вихідного коду без його виконання. Цей метод розглядає відповідність (compliance) як бінарний стан: система або повністю задовольняє визначеним правилам, або містить порушення. Технічно реалізація такого підходу базується на побудові абстрактного синтаксичного дерева (AST) та аналізі байт-коду, що дозволяє інструментам, таким як ArchUnit або NDepend, виконувати перевірки з математичною точністю.

З точки зору формальної логіки, детермінована верифікація базується на апараті теорії множин та орієнтованих графах залежностей. Програмну систему можна представити як орієнтований граф , де:

• — множина компонентів системи (у контексті об’єктно-орієнтованого програмування це класи, інтерфейси або пакети);
• — множина ребер, що відображають залежності між компонентами (імпорти, спадкування, виклики методів).

Функцію архітектурної перевірки  для будь-якої пари компонентів  можна визначити як відображення на множину бінарних значень :

де  означає успішне проходження верифікації (відповідність правилу), а  — наявність архітектурного порушення.

Розглянемо практичний приклад застосування цієї формалізації для контролю меж обмежених контекстів (Bounded Contexts) у Domain-Driven Design. Нехай існує правило, що забороняє пряму залежність контексту продажів від деталей реалізації контексту інвентаризації. Якщо клас  (пакет продажів) має прямий імпорт класу  (пакет інвентаризації), функція перевірки набуде вигляду:

Така бінарна природа результату забезпечує ключову перевагу детермінованого підходу — абсолютну точність виявлення структурних порушень. Якщо інструмент статичного аналізу сигналізує про помилку, це означає, що у графі  гарантовано існує заборонене ребро , що робить такий результат “істинно позитивним” і мінімізує кількість хибних спрацювань. Завдяки цій властивості детерміновані методи ідеально інтегруються у процеси CI/CD як “ворота якості”, дозволяючи автоматично блокувати збірку проєкту при виявленні невідповідностей.

Однак, незважаючи на ефективність у контролі структури, детермінований підхід має суттєві обмеження, зумовлені його природою. Головним недоліком є семантична сліпота. Статичний аналіз оперує синтаксичними конструкціями, але не здатний інтерпретувати семантичну роль компонентів без явного маркування. Наприклад, система не може розрізнити, чи є клас  “Агрегатом” (Aggregate Root), чи звичайною “Сутністю” (Entity), якщо розробник не застосував відповідну анотацію (наприклад, @AggregateRoot) або специфічний патерн іменування. Це призводить до того, що значна частина семантичних правил DDD залишається поза межами контролю.

Крім того, обмеження статичного аналізу унеможливлюють виявлення неявних порушень, таких як дублювання бізнес-логіки. Якщо два мікросервіси містять ідентичні алгоритми розрахунку вартості, але не мають прямих посилань один на одного , детермінована функція перевірки поверне  (успіх), ігноруючи порушення принципу DRY (не повторюй сам себе) та розмивання єдиної мови (Ubiquitous Language), що є критичним для DDD.

Імовірнісний підхід

Обмеження детермінованих методів, зокрема їхня “семантична сліпота” та нездатність інтерпретувати контекст, обумовлюють необхідність застосування альтернативних підходів, що виходять за межі булевої логіки. Імовірнісний підхід до верифікації базується на припущенні, що архітектурна відповідність є не бінарним станом, а ступенем впевненості у тому, що певний фрагмент коду виконує передбачену семантичну роль. Технологічним підґрунтям для цього стають методи обробки природної мови (NLP) та векторні представлення коду (Code Embeddings), які дозволяють трансформувати вихідний код із синтаксичної структури у семантичний простір.

З математичної точки зору, цей підхід передбачає відображення кожного програмного компонента (класу, методу або модуля) у вектор  у багатовимірному дійсному просторі , де  — розмірність простору ознак (наприклад, 768 для моделей на базі трансформерів). Функція вкладення  визначається як:

, де

У такому просторі геометрична близькість векторів корелює із семантичною подібністю компонентів. Для верифікації архітектурних обмежень DDD вводиться поняття еталонного вектора , який репрезентує “ідеальну” реалізацію певного патерну, наприклад, Агрегата (Aggregate) або Об’єкта-Значення (Value Object). Оцінка відповідності класу  певному патерну здійснюється через функцію подібності, найчастіше — косинусну відстань:

Рішення про класифікацію приймається на основі ймовірнісної оцінки. Якщо розрахована подібність (або ймовірність , отримана через softmax-шар класифікатора) перевищує встановлений поріг чутливості , компонент вважається таким, що відповідає патерну:

, якщо

Ключова гіпотеза цього підходу полягає в тому, що векторний аналіз здатний виявляти глибинні семантичні порушення, недосяжні для статичного аналізу. Наприклад, “анемічна модель предметної області” (Anemic Domain Model) — антипатерн, де сутності містять дані, але позбавлені поведінки — матиме векторне представлення, суттєво відмінне від вектора багатої моделі, навіть за умови синтаксичної коректності. Аналогічно, дублювання бізнес-логіки між різними мікросервісами (Bounded Context Leakage) може бути виявлено через високу косинусну подібність векторів методів, які не мають явних посилань один на одного.

На відміну від детермінованого підходу, де точність є абсолютною, імовірнісний метод вимагає балансування між точністю та повнотою. Результати верифікації описуються через матрицю помилок. Впровадження векторного аналізу дозволяє суттєво підвищити метрику Recall, виявляючи приховані архітектурні дефекти (“False Negatives” у контексті статичного аналізу), проте це неминуче призводить до появи певної кількості хибних спрацювань (False Positives), які потребують подальшої фільтрації або експертної оцінки. Такий компроміс є прийнятною платою за можливість автоматизованого контролю семантичної цілісності системи.

Методологія експериментального порівняння

Для верифікації гіпотези про необхідність гібридного підходу до архітектурного контролю було розроблено дизайн контрольованого експерименту. Методологія передбачає порівняльний аналіз ефективності детермінованих алгоритмів та імовірнісних моделей штучного інтелекту на спеціально підготовленому наборі даних, що містить типові порушення принципів Domain-Driven Design (DDD).

Як об’єкт дослідження обрано архітектуру мікросервісної системи електронної комерції, структура якої була визначена у попередніх етапах дослідження. Система декомпозована на два ключові Обмежені Контексти:

1. Sales Context (Продажі): Відповідає за обробку замовлень та взаємодію з клієнтом.
2. Inventory Context (Склад): Інкапсулює логіку управління запасами.

Для проведення експерименту сформовано тестовий набір даних, що включає набір мутацій коду зі штучно внесеними архітектурними дефектами. Класифікація дефектів розроблена для покриття різних рівнів абстракції системи:

• Defect A (Structural Violation): Пряме порушення фізичних меж контекстів. Опис: У модулі src.sales реалізовано прямий імпорт репозиторію з src.inventory, що порушує принцип інкапсуляції сервісів. Це синтаксично видиме порушення.
• Defect B (Semantic Violation): Анемічна модель предметної області (Anemic Domain Model). Опис: Сутність Order реалізована виключно як набір полів даних (Getters/Setters) без бізнес-поведінки, тоді як логіка валідації винесена у сервісний шар. Це порушує тактичний патерн DDD щодо “багатої” моделі, але є синтаксично валідним кодом.
• Defect C (Semantic Leakage): Протікання контексту (Context Leakage). Опис: Дублювання складної бізнес-логіки розрахунку вартості доставки (що належить до Inventory) всередині сервісу Sales. Порушення принципу DRY та єдиної мови (Ubiquitous Language) без створення прямих залежностей між модулями.

Як базовий рівень для порівняння використано підхід “Contract as Code”. Для реалізації застосовано інструментарій статичного аналізу залежностей importlinter для Python, який дозволяє формалізувати архітектурні правила у вигляді конфігураційних файлів.

Верифікація базується на аксіоматичному визначенні “заборонених контрактів” (Forbidden Contracts). Логіка перевірки формулюється наступним чином:

• Правило: Модуль верхнього рівня src.sales не має права залежати від будь-яких підмодулів src.inventory.
• Реалізація: Сканування графа імпортів на наявність ребер , де .

Очікуваний результат: Цей метод забезпечує абсолютну точність для Defect A, оскільки будь-яке виявлене порушення гарантовано є помилкою імпорту. Однак, метод є “семантично сліпим”, тому для Defect B та Defect C очікується показник повноти на рівні 0%, оскільки ці дефекти не порушують правила імпорту.

В якості альтернативного методу досліджується використання Великих Мовних Моделей (LLM), зокрема GPT-4o, які виступають у ролі “семантичного оракула”. Процес верифікації реалізовано через ланцюжок промптів (Chain-of-Thought prompting), де модель аналізує не лише синтаксис, а й контекст та призначення коду.

Алгоритм аналізу включає два напрямки:

1. Семантична класифікація (для Defect B): Модель отримує на вхід код сутності та класифікує її як “Rich Domain Model” або “Anemic Model” на основі наявності методів, що змінюють стан об’єкта згідно з бізнес-правилами.
2. Аналіз семантичної подібності (для Defect C): Використання векторних вкладень (Embeddings) для порівняння функціональних блоків коду. Якщо косинусна подібність логіки у Sales та Inventory перевищує поріг $T$, фіксується потенційне дублювання (leakage).

Для цього підходу оцінка фокусується на балансі метрик. Очікується високий рівень Recall для всіх типів дефектів, однак існує ризик зниження точності через можливі галюцинації моделі або хибну інтерпретацію легального коду як порушення.

Результати експериментального порівняння

Проведене експериментальне дослідження підтвердило фундаментальну гіпотезу про взаємодоповнюваність детермінованих та імовірнісних методів у задачі архітектурної верифікації. Отримані дані свідчать, що жоден із підходів у ізольованому вигляді не здатний забезпечити повне покриття вимог Domain-Driven Design (DDD), оскільки природа архітектурних порушень варіюється від чітких структурних помилок до складних семантичних відхилень.

Приклад запуску детермінованої перевірки із виявленими помилками:

(ci-cd) PS D:\Навчання\KHAI\dev\ci-cd> lint-imports

Analyzed 5 files, 1 dependencies.

———————————

DDD: Sales Context must not depend on Inventory Context implementation BROKEN

Contracts: 0 kept, 1 broken.

—————-

Broken contracts

—————-

DDD: Sales Context must not depend on Inventory Context implementation

————————————————————-

src.sales is not allowed to import src.inventory:

–   src.sales.service -> src.inventory.repository (l.2)

Приклад запуску імовірнісної перевірки із виявленими помилками:

— ПЕРЕВІРКА 1: Anemic Domain Model (Defect B) —

… Аналіз LLM запущено…

Висновки LLM:

{

“is_anemic”: true,

“reason”: “Order class primarily holds data and contains simple calculations for total price and status retrieval, lacking significant business logic such as state transitions or validations directly within the class.”,

“suggestion”: “Consider adding methods to change the order status, apply discounts with business rules, validate items, update items, and ensure order integrity to encapsulate business behavior within the class.”

}

✅ Успіх: Defect B (Anemic Model) виявлено!

— ПЕРЕВІРКА 2: Context Leakage / Duplication (Defect C) —

… Аналіз LLM запущено…

Висновки LLM:

{

“is_leakage”: true,

“similarity_index”: 1.0,

“common_logic_domain”: “Sales”,

“reason”: “The Inventory Context contains a method ‘calculate_discount_for_estimation’ that duplicates the discount calculation logic from the Sales Context. This leads to Context Leakage, as inventory logic should not include sales-based discount calculations. Instead, the logic should remain isolated within the Sales Context to ensure clear separation of concerns.”

}

✅ Успіх: Defect C (Context Leakage) виявлено! Схожість: 1.00

Результати вимірювання ефективності методів на тестовому наборі даних, що містив структурні (Defect A) та семантичні (Defect B, C) порушення, наведено у Таблиці 1.

Таблиця 1

Аналіз даних демонструє чітку спеціалізацію кожного методу. Детермінований підхід (реалізований через статичний аналізатор) виступає еталоном для перевірки структурних обмежень, забезпечуючи абсолютну точність. Це означає повну відсутність хибних спрацювань (False Positives), що є критичним фактором для інтеграції інструменту в автоматизовані пайплайни, де кожне блокування збірки має бути обґрунтованим. Однак, показник повноти для семантичних дефектів дорівнює 0%, що підтверджує “семантичну сліпоту” інструментів, які працюють виключно з синтаксичним деревом коду.

На противагу цьому, імовірнісний підхід на базі LLM продемонстрував високу здатність до виявлення прихованих семантичних проблем, досягнувши показника повноти 90% для дефектів типу “Анемічна модель” та “Протікання контексту”. Водночас, знижена точність (80%) вказує на наявність шуму в результатах, коли коректні архітектурні рішення помилково класифікувалися як порушення через неоднозначність контексту.

Для якісної оцінки можливостей методів було сформовано матрицю (Таблиця 2), яка відображає придатність кожного підходу для виявлення специфічних типів порушень DDD.

Таблиця 2

Як видно з матриці, детерміновані методи є безальтернативними для задач, що піддаються суворій формалізації. У той же час, імовірнісні методи ефективно закривають зону критеріїв якості таких як відповідність коду єдиній мові (Ubiquitous Language) та правильність розподілу відповідальності між агрегатами, що є основою стратегічного проєктування в DDD. Отримані результати дозволяють чітко розмежувати ролі досліджуваних інструментів у процесі розробки програмного забезпечення. Завдяки абсолютній точності, статичні аналізатори повинні використовуватися як “жорсткий” фільтр синтаксичного контролю. Вони можуть бути налаштовані на автоматичне блокування CI/CD пайплайну у випадку виявлення порушень, оскільки ризик зупинки процесу через помилкове спрацювання є мінімальним. Враховуючи наявність хибних спрацювань, але високу чутливість до семантики, LLM-інструменти доцільно використовувати в режимі “м’якого” асистента або системи раннього попередження. Результати їхнього аналізу мають надходити на розгляд розробнику для валідації, не блокуючи процес розгортання автоматично.

Таким чином, ключовим висновком дослідження є необхідність переходу від конкурентного протиставлення методів до створення гібридної системи верифікації. Така система має використовувати статичний аналіз для швидкої відсічі грубих структурних порушень, та передавати очищений контекст до інтелектуального модуля для глибинного семантичного аналізу. Перспективи подальших досліджень полягають у розробці механізмів зменшення рівня хибних спрацювань імовірнісних моделей, зокрема шляхом використання RAG з архітектурною документацією проєкту як контекстом, що дозволить підвищити точність семантичної верифікації.

Висновки. У межах проведеного дослідження було здійснено комплексний порівняльний аналіз детермінованих та імовірнісних методів верифікації архітектурних обмежень у мікросервісних системах, а також вирішено науково-прикладне завдання автоматизації контролю відповідності принципам Domain-Driven Design. В результаті експериментального дослідження визначено, що ефективний контроль архітектурної якості неможливий у рамках єдиної методологічної парадигми, оскільки природа архітектурних вимог варіюється від чітких структурних правил до складних семантичних концепцій. Встановлено фундаментальну відмінність у застосуванні підходів: детерміновані методи забезпечують жорсткий контроль синтаксичної коректності залежностей, тоді як імовірнісні моделі є необхідним інструментом для інтерпретації контексту та семантики бізнес-логіки, долаючи бар’єр “семантичної сліпоти” традиційних інструментів.

Експериментальна апробація на прикладі мікросервісної взаємодії контекстів Sales та Inventory дозволила емпірично підтвердити гіпотезу про комплементарність досліджуваних методів. Отримані метрики засвідчили, що детерміновані алгоритми гарантують абсолютну точність при виявленні порушень фізичних меж контекстів, що є критичним для автоматизованих блокувань у CI/CD, проте виявляються безсилими перед архітектурними антипатернами на кшталт анемічної моделі. Водночас застосування великих мовних моделей продемонструвало високу повноту виявлення прихованих семантичних дефектів та протікань контексту, хоча й супроводжувалося зниженням точності через наявність стохастичного шуму.

Таким чином, результати дослідження обґрунтували необхідність впровадження гібридної моделі архітектурної верифікації, яка поєднує надійність статичного аналізу з аналітичним потенціалом штучного інтелекту. Доцільність такої інтеграції підтверджується необхідністю балансування між мінімізацією ризиків зупинки розробки через хибні спрацювання та потребою у глибокому аналізі бізнес-правил. На основі цього визначено пріоритетні напрями подальших досліджень, що охоплюють розробку адаптивних механізмів фільтрації результатів імовірнісного аналізу та інтеграцію технологій RAG для використання проєктної документації як контексту верифікації. Реалізація запропонованих підходів дозволить створити дворівневу систему захисту архітектури, що забезпечить її довгострокову стійкість та відповідність бізнес-вимогам в умовах динамічної еволюції програмних систем.

Література

1. Richards M., Ford N. Fundamentals of Software Architecture: An Engineering Approach. O’Reilly Media, 2020. 245 p. https://mrce.in/ebooks/Software-Fundamentals%20of%20Software%20Architecture.pdf
2. Binkley D. Source Code Analysis: A Road Map. IEEE Computer Society, 2007. https://www.academia.edu/2857153/Source_code_analysis_A_road_map
3. Humble J., Farley D. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley Professional, 2010.
4. Allamanis M., Barr E. T., Devanbu P., Sutton C. A Survey of Machine Learning for Big Code and Naturalness. ACM Computing Surveys. 2018. https://arxiv.org/pdf/1709.06182
5. Alon U., Zilberstein M., Levy O., Yahav E. code2vec: Learning Distributed Representations of Code. Proceedings of the ACM on Programming Languages (POPL). 2019. https://dl.acm.org/doi/pdf/10.1145/3290353
6. Feng Z. et al. CodeBERT: A Pre-Trained Model for Programming and Natural Languages. Findings of the Association for Computational Linguistics: EMNLP 2020. https://arxiv.org/pdf/2002.08155
7. Arcelli Fontana F., Mäntylä M. V., Zanoni M., Ranchetti A. Comparing and Experimenting Machine Learning Techniques for Code Smell Detection. Empirical Software Engineering. 2016. https://mmantyla.github.io/Fontana_EMSE_2016_Comparing_and_Experimenting_Machine_Learning_Techiniques_for_Code_Smell_Detection.pdf
8. Sharma T., Fragkoulis M., Spinellis D. House of Cards: Code Smells in Open-Source C# Repositories. Proceedings of the 2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). 2017. https://www.researchgate.net/publication/321741298_House_of_Cards_Code_Smells_in_Open-Source_C_Repositories
9. Hou X. et al. Large Language Models for Software Engineering: A Systematic Literature Review. arXiv preprint arXiv:2308.10620, 2023. https://arxiv.org/pdf/2308.10620
10. Fowler M. The Anemic Domain Model. 2003. https://martinfowler.com/bliki/AnemicDomainModel.html