Архітектурний рефакторинг змінює межу, не контракт
Зовнішніми споживачами є не лише користувачі: це API-клієнти, модулі, тести, event subscribers та інші сервіси. Архітектурний рефакторинг може винести відповідальність у collaborator або interface, але endpoint, topic, payload, сигнатури й порядок side effects мають залишитися незмінними.
Наприклад, публікацію подій можна винести з OrderService в OrderEventPublisher, якщо бізнес-логіка не змінює зовнішній topic і payload.
| Межа | Що зберегти |
|---|---|
| REST API | Маршрути, статуси, body і публічні сигнатури |
| Event integration | Topic, payload і порядок публікації |
| Data flow | Записи, транзакції та observable side effects |
| Architecture | Чіткіша відповідальність без прихованої міграції |
Що не можна непомітно додати до refactor
- зміну REST-відповідей або публічних сигнатур;
- перейменування topic чи зміну формату події;
- оновлення Spring, Kafka або інших залежностей;
- зміну бізнес-правил і виправлення помилок;
- зміну transport або serialization config;
- широкий cleanup у сусідніх модулях.
План архітектурної зміни
- Зафіксуйте поточну поведінку integration, API та characterization-тестами.
- Визначте одну архітектурну межу для очищення.
- Винесіть відповідальність у collaborator або interface без зміни контракту.
- Працюйте малими кроками без dependency updates і стороннього formatting.
- Запустіть застосовні unit, integration, build, lint і type-check перевірки.
- Перевірте diff та можливість одного логічного revert.
Критерії приймання PR
| Критерій | Що підтвердити |
|---|---|
| Поведінка | Зовнішні результати й контракти незмінні |
| Scope | Diff обмежений однією ідеєю |
| Quality | Релевантні перевірки успішні |
| Architecture | Відповідальність класів стала зрозумілішою |
| Safety | Немає випадкових залежностей, config changes або migration |
| Recovery | Зміни легко відкотити одним revert |
Роль людини у прийманні
Інструменти та тести надають докази, але не визначають межі задачі самостійно. Людина вирішує, чи є зміна справді рефакторингом, чи потрібно розділити роботу, чи покращує interface архітектурну межу і чи достатньо зрозумілий PR для безпечного приймання.
В описі PR окремо покажіть мету, affected files, non-goals, виконані команди, оцінку ризику та статус збереження поведінки.
Канонічне джерело уроку · JavaRush
Відкрити матеріал JavaRush