Перейти до основного вмісту

Сервіс

Наша стратегія розробки базується на ідеї використання сервісів як окремих компонентів функціональності, які можна розглядати та розробляти незалежно один від одного. Кожен сервіс відповідає за виконання конкретного завдання або надання певної послуги.

інформація

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

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

інформація

Замість того, щоб будувати веб-застосунок як єдину монолітну систему, ми розглядаємо його як модульний моноліт - сукупність таких сервісів, які можуть взаємодіяти один з одним. Це дає можливість гнучко використовувати систему

порада

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

порада

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

Архітектура​

Кожний графічний інтерфейс, який потребує включення бізнес-логіки, встановлює ядро відображення, що забезпечує роботу сервісу, або групи сервісів.

При описі кожного графічного інтерфейсу є можливість описати, які саме сервіси будуть в ньому використанні. Використання сервісів, в контексті X-Fiber це використання графічних представлень предметних областей цих сервісів.

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

порада

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

примітка

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

Склад​

Опис сервісу має наступний вид:

type RegistryStructure = {
    // ... registry structure
}

type ServiceDocumentation<N extends string = string> = {
    // ... service documentation structure
}

type ServiceStructure<S extends string = string> = {
    service: S;
    domains: RegistryStructure[];
    documentation?:
        | ServiceDocumentation
        | ServiceDocumentation[]
        | null;
};

export const setService = <S extends string = string>(
    service: S,
    domains: RegistryStructure[],
    documentation?:
        | ServiceDocumentation
        | ServiceDocumentation[]
        | null
): ServiceStructure<S> => {
    return {service, domains, documentation};
};

де:

  • Типи:
    • RegistryStructure - документ "Реєстр" предметної області, який реєструє похідні документи веб-клієнта.
    • ServiceDocumentation - опис документації сервісу, його інтерфейсів та ін. конкретною мовою перекладу, будь-то en, ru чи ін.
    • ServiceStructure - сформований обʼєкт сервісу для подальшої реєстрації в setServices ядра відображень.
    • setService - вбудована функція в ядро відображень, яка призначена для опису сервісів бізнес-схеми.
    • S - строковий тип назви сервісу, який повинен бути унікальним в рамках бізнес-схеми одного ядра відображень.
  • Аргументи:
    1. service - ідентифікаційний тег, який однозначно визначає сервіс.
    2. domains - перелік функціональних сфер, які охоплює конкретний сервіс.
    3. documentation - детальний опис функціональності, інтерфейсів, параметрів виклику та іншої важливої інформації про сервіс. Ця документація допомагає розробникам та іншим зацікавленим особам розуміти, як користуватися сервісом.
  • Результат:
    • Сформований опис бізнес-схеми сервісу, який необхідно зареєструвати в setServices ядра відображень.
warning

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

Реалізація​

порада

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

інформація

Декомпозиція коду на модулі полягає у розділенні програмного коду на невеликі, самодостатні блоки, які відповідають за конкретні функціональні області програми. X-Fiber надає перелік вбудованих документів - невеликих блоків, через, які необхідно описувати функціональну сферу.

import { setService } from 'x-fiber/display'
import {
    BusUsersAgg,
    BusUsersAuthSpec,
    BusUsersRolesSpec,
    BusUsersRolesPermissionsSpec
} from './bus.users'

export const Service1 = setService<"BusinessAdmin" | "Accounting">('BusinessAdmin', [
    BusUsersAgg,
    BusUsersAuthSpec,
    BusUsersRolesSpec,
    BusUsersRolesPermissionsSpec,
]);

де:

  • BusinessAdmin - назва сервісу.
  • [BusUsersAgg, BusUsersAuthSpec, ...] - масив предметних областей.

Предметна область​

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