Основна помилка полягає у тому, що більшість розробників використовують події (events) не як повідомлення про зміни, що відбулися, а як команди. У такому випадку відбувається більш сильне зв’язування сервісів у системі, оскільки вони знають один про одний та починають оркеструвати роботу інших сервісів.
Я бачив таку помилку у багатьох проєктах, в які підключався як розробник та в яких працював як консультант аби витягти команди з трясовини анти-патернів. У результаті такої помилки система, яка планувалась як сервісна чи т.з. “мікро-сервісна”, насправді, представляла собою розподілений моноліт.
Розглянемо приклад інтернет-магазину, де окрім інших є два наступні сервіси:
- сервіс через який клієнт оформлює замовлення (A)
- сервіс через який менеджери з продажів обслуговують замовлення (B)
Сервіс, який оформлює замовлення (A) отримує список покупок від покупця і контактні дані та зберігає замовлення.
Сервіс з яким працюють менеджери з продажів (B) розкидує завдання між менеджерами аби ті дзвонили клієнтам для підтвердження замовлень та у випадку підтвердження передавали обробку замовлень далі, наприклад, на склад.
Помилка
Сервіс A має якось повідомити про нове замовлення інші сервіси, зокрема сервіс через B. Явною помилкою буде безпосередне звернення A до B, оскільки, в цьому випадку A має знання про B.
Менш очевидною помилкою є додавання в чергу повідомлення про те, що сервіс B має опрацювати нове замовлення. Нехай це повідомлення називається “ConfirmOrder”. Назва “ConfirmOrder” – вже виглядає як команда.
У такому випадку сервіс A не знає безпосередньо про сервіс B, але він знає, що замовлення має бути підтверджене, тобто про щось, що виконує функцію сервісу B. Насправді, різниця між першим та другим підходами полягає лише в наявності посередника – черги повідомлень. З точки зору збільшення сплутанності системи (coupling) обидва підходи еквівалентні.
Правильне рішення
Правильним рішенням буде повідомлення про те, що замовлення було зареестроване. У такому випадку сервіс лише повідомляє про те, що він завершив роботу і якщо комусь для чогось необхідні результати його роботи, то вони можуть їх отримати, підписавшись на подію реестрації замовлення. Воно може називатися просто “Order” або “OrderCreated”. У такому випадку сервіс А не знає нічого зайвого і ми отримуєму слабдку сплутаність (low coupling).
P.S.
Мова йде не лише про сервісну чи мікро-сервісну архітектури, а про роботу з подіями взагалі. Наприклад, ця ж рекомендація буде корисною і для роботи з DOM подіями у браузері.
Залишити відповідь