Репозиторій високопродуктивного, масштабованого бекенд-рушія для управління фінансовими транзакціями, гаманцями та аналітикою рахунків. Проєкт розроблено на платформі .NET 8 / ASP.NET Core із суворим дотриманням принципів Clean Architecture (Чистої архітектури) та архітектурного шаблону CQRS (Command Query Responsibility Segregation).
Даний документ слугує офіційним архітектурним звітом та документацією для Лабораторної роботи №2 з дисципліни «Основи ООП» (Розділ: Патерни проєктування GoF).
Проєкт розділений на слабозв'язані шари (проекти всередині рішення), де залежності спрямовані виключно всередину, до бізнес-логіки (Domain):
- Domain (Ядро системи): Містить сутності (Entities), такі як
Transaction,Wallet,User, об'єкти-значення (Value Objects) та бізнес-правила. Не має жодних зовнішніх залежностей. - Application (Прикладна логіка): Визначає інтерфейси взаємодії, моделі даних (DTO), правила валідації (FluentValidation) та безпосередньо реалізує CQRS-шаблон за допомогою бібліотеки
MediatR. Шари розділені на команди (Commands — зміна стану) та запити (Queries — отримання даних). - Infrastructure (Інфраструктура): Реалізує доступ до баз даних за допомогою Entity Framework Core, керує міграціями (PostgreSQL/SQL Server), транзакціями бази даних та інтеграцією із зовнішніми сервісами.
- API (Шар представлення): Набір REST контролерів ASP.NET Core, які приймають HTTP-запити, передають їх в шар Application та повертають уніфіковані відповіді.
В архітектурі SmartFinanceEngine класичні патерни банди чотирьох (GoF) інтегровані безпосередньо в каркас додатку, що забезпечує гнучкість, низьку зв'язність (Low Coupling) та високу згуртованість (High Cohesion) коду. Відповідно до вимог, реалізовано патерни з усіх трьох категорій.
- Де використовується в коді: Реалізований через інтерфейс
IMediatorбібліотекиMediatRв шарі API (Контролери) та шарі Application. - Суть реалізації: REST-контролери (наприклад,
TransactionsController) не залежать від сервісів інфраструктури чи конкретних обробників бізнес-логіки. Вони лише формують об'єкт запиту/команди і викликають метод_mediator.Send(command). - Призначення та переваги: Усуває прямі залежності типу «багато до багатьох» між контролерами та логікою обробки. При додаванні нових фінансових операцій код контролерів залишається незмінним, що повністю задовольняє принцип OCP (Open/Closed).
- Де використовується в коді: Класи команд у папках
Application/Transactions/Commands/(наприклад,CreateTransactionCommand,UpdateWalletCommand). - Суть реалізації: Кожна фінансова дія інкапсулюється в окремий POCO-клас, який містить усі необхідні вхідні параметри для операції та реалізує маркерний інтерфейс
IRequest<T>. - Призначення та переваги: Перетворення запиту на дію в об'єкт дозволяє передавати його через конвеєр обробки, виконувати пре-валідацію, логувати структуру запиту та ізолювати контекст виконання.
- Де використовується в коді: Конвеєри обробки MediatR (
IPipelineBehavior<TRequest, TResponse>), розташовані в шаріApplication/Common/Behaviors/. - Суть реалізації: Створено класи-декоратори, такі як
ValidationBehaviorтаLoggingBehavior. Вони перехоплюють виконання будь-якоїCommandабоQueryперед тим, як вона потрапить до свого основного обробника (CommandHandler). - Призначення та переваги: Дозволяє динамічно розширювати поведінку обробки запитів (додавати автоматичну валідацію через FluentValidation, логувати час виконання, відкривати системні транзакції БД) без зміни коду самих команд чи обробників. Це чиста реалізація принципу SRP (Single Responsibility).
Де використовується в коді: Клас контексту бази даних ApplicationDbContext : DbContext в інфраструктурному шарі.
Суть реалізації: Entity Framework Core надає клас DbContext, який виступає високорівневим уніфікованим інтерфейсом (Фасадом) до складної підсистеми роботи з СУБД (PostgreSQL/SQL Server).
Призначення та переваги: Прикладному розробнику не потрібно вручну відкривати сокети, писати сирі SQL-запити, мапити рекорди на об'єкти чи керувати пулом з'єднань. Фасад ховає низькорівневу логіку ADO.NET за простими методами маніпуляції колекціями DbSet.
Де використовується в коді: Конфігурація сервісів у файлі Program.cs за допомогою IServiceCollection.
Суть реалізації: Використання патернів Singleton, Scoped та Transient для управління життєвим циклом об'єктів. Реєстрація сервісів абстракцій (наприклад, builder.Services.AddScoped<IApplicationDbContext, ApplicationDbContext>();).
Призначення та переваги: Контейнер виступає як глобальна абстрактна фабрика об'єктів. Класи системи більше не створюють залежності через оператор new, а декларують їх у конструкторах. Об'єктна ієрархія збирається автоматично в момент запиту.
Де використовується в коді: Ініціалізація веб-додатку в Program.cs: var builder = WebApplication.CreateBuilder(args);.
Суть реалізації: Конструювання об'єкта конфігурації хоста за допомогою каскаду методів (Fluent API) для поетапного додавання сервісів, логування, middleware-компонентів.
Призначення та переваги: Дозволяє будувати складний об'єкт WebApplication крок за кроком, ізолюючи конфігурацію середовища, Kestrel, DI-сервісів та логерів перед фінальним викликом методу builder.Build().
Проєкт спроєктовано як демонстрацію стійких практик програмної інженерії:
Кожна команда валідується окремим класом Validator, обробляється своїм CommandHandler, а сутності відображають лише стан бізнес-моделі.
Створення нової фінансової аналітики вимагає лише написання нової пари Query + QueryHandler. Жоден існуючий клас додатку при цьому не модифікується.
Будь-яка реалізація IApplicationDbContext може бути підставлена в хендлери без порушення коректності роботи логіки додатку.
Інтерфейси MediatR чітко розділені: IRequest для медіатора, IRequestHandler<TIn, TOut> для хендлера. Класи реалізують лише мінімально необхідні контракти.
Шар Application не залежить від шару Infrastructure. Доступ до бази даних абстраговано через інтерфейс IApplicationDbContext. Впровадження конкретної реалізації виконується на рівні запускного проєкту (API) через DI.
Усі public-класи, інтерфейси команд, методи контролерів та обробники бізнес-логіки покриті стандартизованими коментарями ///
Проєкт містить супутній тестовий модуль, який за допомогою xUnit/Moq покриває ключові компоненти шару Application, тестуючи поведінку фінансових обробників як для валідних вхідних даних, так і для нестандартних ситуацій (нестача балансу, неіснуючі гаманці).
Відповідно до пунктів 83-85 «Загальних вимог до завдань» дисципліни «Основи ООП», у даному проєкті офіційно задекларовано використання технологій ШІ:
Інструмент: Google AI Studio (модель Gemini 1.5 Pro).
Сфера застосування (Prompt Engineering): ШІ використовувався для автоматизації рутинного процесу написання стандартних XML-коментарів (///) до методів обробки CQRS-команд, генерації заготовок валідаційних правил FluentValidation на основі бізнес-вимог та структурування даного архітектурного README-звіту.
Контроль якості: Увесь генерований код та коментарі пройшли ретельний ручний аналіз та редагування автороми проєкту. Повну відповідальність за працездатність системи та відсутність помилок несе студент-виконавець.