Меню документації

Технічна концепція OwlMeans

На цій сторінці

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

Як взаємодіють складові

flowchart TD
    A[User interface and forms] --> B[Application behavior]
    B --> C[Authorization and services]
    C --> D[Database and shared state]
    E[Configuration and project guidance] --> A
    E --> B
    E --> C

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

Спільні визначення допомагають узгоджувати зміни

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

Конфігурація дає застосунку єдиний спосіб знаходити свої сервіси. Робоче оточення агента (agent harness) описує ці домовленості, тож новий агент може розширювати наявну структуру, не перебудовуючи основу.

Чим допомагає ця структура

  • Узгоджені зміни: новий екран дотримується тих самих домовленостей щодо форм, сервісів і доступу, що й попередні екрани.
  • Чіткі дозволи: ідентифікація та авторизація закладені в основу застосунку, тож правила доступу можуть відповідати бізнес-логіці.
  • Повторно використовувані складові: OwlMeans Common надає значну частину спільного коду застосунку. Можете присвятити більше часу тому, щоб описати поведінку, потрібну користувачам.
  • Наступність роботи агентів: спеціально налаштовані навички та памʼять проєкту пояснюють домовленості агенту, який долучається пізніше.
  • Можливість зростання: розподіл відповідальності полегшує розширення застосунку, коли зʼявляються нові вимоги.

Основу цього підходу становлять домовленості проєкту create-app і публічні пакети OwlMeans Common. Сторінки про технології пояснюють призначення допоміжних бібліотек.

Застосуйте на практиці

  1. Опишіть бізнес-результат і ролі користувачів у специфікації.
  2. Зосередьте користувацьку історію на поведінці, яку можна продемонструвати.
  3. Попросіть агента дотримуватися наявної архітектури проєкту, коли він додає функцію.
  4. Перевіряйте екран, збережені записи й дозволи разом.
  5. Зберігайте робоче оточення та памʼять, коли передаєте розробку іншому агенту.

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

Приклад застосунку

Категорія: CRM і керування клієнтами. Приклад: CRM для невеликої команди з призначенням відповідальних за контакти та доступом для керівника.