Software Engineering

Еволюція проєктних рішень

У нашому швидкоплинному світі компанії не можуть дозволити собі навіть найменшу пасивність. Щоб не відстати від конкурентів, їм доводиться постійно змінюватися, розвиватися і навіть з часом знову «винаходити себе».

Еволюція проєктних рішень

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

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

У цій главі розглядаються питання впливу змін у навколишньому середовищі програмного проєкту на проєктні рішення і завдання відповідної еволюції проєкту.

Вектори Змін

Потрапляють чотири найбільш поширених вектори змін:

items:

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

Зміни в Предметних Областях

Тип піддомену впливає на стратегічні та тактичні проєктні рішення. Проте піддомени не є статичними; вони трансформуються з одного типу в інший.

Сценарії трансформації

З Основного в Універсальний: Коли ваша інновація стає загальнодоступним ринковим товаром (commodity).
З Універсального в Основний: Коли компанія замінює готове рішення власною розробкою для отримання конкурентної переваги. (Приклад: Amazon AWS).
З Допоміжного в Універсальний: Коли з'являється готове рішення або open-source проєкт, що покриває потреби допоміжної логіки.
З Допоміжного в Основний: Якщо бізнес знаходить спосіб перетворити просту логіку на джерело прибутку або серйозної економії.
З Основного в Допоміжний: Якщо складність піддомену більше не виправдовує себе і логіка спрощується.
З Універсального в Допоміжний: Коли інтеграція готового рішення виявляється дорожчою за підтримку власної простішої системи.

Еволюція типів піддоменів

Стратегічні Аспекти Проєктування

Зміна типу піддомену безпосередньо впливає на патерни інтеграції.

Основні піддомени повинні бути реалізовані всередині компанії (in-house), ближче до джерел знань. Допоміжні ж можна передати на аутсорсинг.

Вплив на патерни інтеграції:

Захист моделі: Основні піддомени потребують ACL та OHS.
Відмова від Separate Ways: Якщо піддомен стає основним, дублювання функцій стає неприпустимим; команди повинні інтегруватись (зазвичай через Customer-Supplier).

Тактичні Аспекти Проєктування

Сигналом про зміну типу піддомену часто є неспроможність поточного дизайну підтримувати потреби бізнесу.

Не бійтеся переглядати стратегію моделювання бізнес-логіки. Перехід від простіших патернів до складніших — це нормальний процес еволюції системи.

Шлях еволюції патернів:

Transaction Script → Active Record Коли робота з даними ускладнюється, інкапсулюйте структури даних в об'єкти Active Record для абстрагування моделі зберігання.
Active Record → Domain Model Коли логіка маніпулювання даними стає заплутаною, виділяйте Value Objects, визначайте межі транзакцій та перетворюйте Active Record на Агрегати.
Domain Model → Event-Sourced Domain Model Якщо потрібна повна історія змін та глибокий аналіз, переходьте до моделювання подій предметної області замість простої зміни стану.

Міграція на Event Sourcing

При перетворенні існуючої системи на Event Sourcing виникає проблема відсутності історії минулих станів.

// Спроба відтворити потік подій на основі поточного стану
{
  "lead-id": 12,
  "event-type": "lead-initialized",
  "first-name": "Shauna"
},
{
  "event-type": "order-submitted",
  "timestamp": "2020-05-27"
}

// Явне визначення точки переходу
{
    "lead-id": 12,
    "event-type": "migrated-from-legacy",
    "status": "converted",
    "balance": 150.0
}

Організаційні Зміни

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

Розбиття обмежених контекстів через ріст команд

Еволюція відносин між командами:

Партнерство → Споживач-Постачальник: Коли команди віддаляються, і синхронізація стає важчою.
Споживач-Постачальник → Separate Ways: Коли витрати на інтеграцію та очікування стають вищими за переваги спільного використання.

Ріст Проєкту та «Великий Клубок Бруду»

«Великий клубок бруду» — безладний, розпадаючийся, що складається з костилів та ізоляційної стрічки лапшекод.
— Брайан Фут і Джозеф Йодер

Настанови щодо боротьби зі складністю:

Піддомени: Переглядайте межі. Шукайте «приховані» піддомени, які можна виділити в окремі компоненти.
Обмежені контексти: Не дозволяйте їм ставати «про все і ні про що». Підвищуйте автономність, усуваючи зайву «балакучість» між сервісами.
Агрегати: Дотримуйтесь правила мінімального розміру. Якщо агрегат розростається — розбивайте його.

Рафінування піддоменів

Висновок

items:

title: Динамічність типів description: Постійно перевіряйте, чи не змінився тип вашого піддомену.
title: Еволюція коду description: Будьте готові змінювати тактичні патерни (Script -> Active Record -> Domain Model).
title: Управління ростом description: Боротьба з «великим клубком бруду» вимагає постійного рафінування меж.

Завдання

Які зміни в інтеграції контекстів часто викликаються ростом організації?

::steps 2. Що означає перехід від конформіста до моделі різних шляхів (Separate Ways)? ::

::steps 3. Які ознаки перетворення допоміжного піддомену в основний? ::

::steps 4. Яка зміна може перетворити універсальний піддомен WolfDesk в основний? ::

Edit this pageorReport an issue

Евристика проєктування

EventStorming

У цій главі ми зробимо перерву в розгляді патернів та технік проєктування, і зосередимо увагу на нескладному процесі моделювання під назвою EventStorming.