У цій статті
Перевірте межі на прикладі замовлення
Уявіть продукт із каталогом, замовленнями й рахунками. Модульний моноліт зберігає одне розгортання з явними інтерфейсами модулів. Замовлення не мають безпосередньо змінювати таблиці рахунків лише через спільну БД. Корисна межа показує бізнес-відповідальність до перетворення на мережеву.
Пройдіть сценарій скасування замовлення після виставлення рахунка. Хто дозволяє скасування? Які записи змінюються разом? Де компенсація? Якщо команда не відповідає всередині одного процесу, поділ на сервіси розподілить неоднозначність. Spring Modulith допомагає моделювати модулі, але предметні рішення залишаються за командою.
Де проходить межа?
Обидва підходи потребують зрозумілої відповідальності за бізнес-функції.
Модульний моноліт
Модулі в одному розгортанні. Межі дотримуються всередині застосунку.
Мікросервіси
Незалежні розгортання. Межі проходять також через мережу, сховища й експлуатацію.
Починайте з мінімальної керованої межі
Модульний моноліт поєднує розгортання, спостережуваність і узгодженість даних, зберігаючи предметні межі в коді. Часто це безпечніше для однієї команди та спільного ритму випусків.
Мікросервіси корисні за реальних стійких вимог незалежної відповідальності, масштабування, доступності чи випуску. Ранній поділ лише перетворює кодові межі на мережеві, інформаційні й інцидентні.
Перевіряйте межі до розподілення
Виділяйте модулі за бізнес-можливостями, задавайте напрям залежностей і забороняйте доступ до чужих таблиць. Якщо модульність не витримує одного процесу, API й черги не зроблять її зрозумілішою.
Відстежуйте спільні зміни модулів, конкуренцію за ресурси й відмінності вимог надійності. Це вагоміші сигнали для виділення, ніж кількість класів чи розмір репозиторію.
Виділяйте сервіс із планом відновлення
До виділення призначте власника, визначте повноваження над даними, поведінку за збоїв, вікно сумісності, телеметрію й відкат. Подвійний запис без звіряння створює дві конкурентні істини.
Виділіть одну обґрунтовану межу, виміряйте усунення початкового обмеження й залиште решту простою. Розподілена архітектура — постійне експлуатаційне зобов’язання, не разовий рефакторинг.
Що виділення додає звичайному запиту
Після виділення рахунків замовлення може бути прийняте, поки рахунок затримується. Інтерфейс має показувати проміжний стан. Повтор не має виписати другий рахунок, а стара подія — перезаписати нове скасування. Це поведінка продукту тією самою мірою, що й інфраструктурні питання.
До виділення намалюйте стани й власників переходів. Де клієнт бачить очікування, хто звіряє незавершену роботу й розслідує завислий запис? Якщо потрібна транзакція «усе або нічого» для кожної зміни, перегляньте межу. Тісно пов’язану роботу розумніше тримати разом, доки бізнес не може прийняти й пояснити частковий прогрес.
Виділіть одну можливість і виміряйте результат
Переконливий кандидат зазнає конкретного тиску: окремий ритм випуску, власна команда чи істотно інший профіль ресурсів. Спочатку зафіксуйте базу. Перенесіть один інтерфейс і володіння його даними, збережіть сумісність під час випуску та перевірте зменшення початкової проблеми.
Оцініть координацію випусків, чергування й час простежування запиту. Якщо кожна зміна все ще потребує одночасного випуску всіх команд, імовірний розподілений моноліт. Зупиніть виділення до розуміння зв’язності. Мета — відповідність меж роботі, а не кількість сервісів чи ефектна схема.
Джерела й додаткові матеріали
Документацію перевірено .
ЗАПИТАННЯ / РІШЕННЯ
Поширені запитання
Мікросервіси за замовчуванням краще масштабуються?+
Ні. Вони допускають незалежне масштабування за відповідних меж і навантаження, але додають витрати на мережу, узгодженість, випуск та інциденти.