Folosește protocoale, nu servicii: de ce codul tău are nevoie de o dietă

Imaginați-vă că mergeți la restaurant, iar chelnerul, în loc de meniu, vă aduce documentația completă a bucătăriei: "Acesta este serviciul de livrare a ingredientelor, acesta este serviciul de tăiat legume..." Cam așa arată codul în care, în loc de protocoale clare de comunicare, ai o grămadă de servicii umflate. Dezvoltatorul Not Not P (da, un astfel de pseudonim) sugerează tratarea acestei arhitecturi obosite.

Ideea este simplă ca o bătaie: conveniți asupra formatului datelor și acțiunilor (protocol), nu trageți după voi un serviciu întreg cu metodele sale. E ca și cum ați trece de la "îl sun pe Vasile, el îi transmite lui Petre" la un simplu "trimite JSON pe portul 8080". Mai puțini intermediari — mai puțină durere de cap la deploy.

Desigur, lumea e plină de arhitecturi hype, unde microserviciile se înmulțesc ca iepurii. Dar autorul ne amintește: dacă serviciul tău știe doar "getUser" și "saveUser", poate că e timpul să nu-l mai numești serviciu? Un protocol cu două operații nu este un serviciu, ci o funcție. Și pentru o funcție nu-ți este rușine, rușine este pentru 47 de coloane în JIRA de dragul ei.

De ce funcționează

• Flexibilitate: protocolul poate fi reutilizat în diferite servicii, fără a rescrie API-ul de fiecare dată.
• Testabilitate: e mai ușor să testezi un protocol decât să mochezi un serviciu întreg cu dependențele sale.
• Evoluție: protocolul trăiește mai mult decât implementarea specifică — schimbați serviciile, păstrând contractul.

Comentariul studioului METABYTE: Și nouă ne plac protocoalele slabe — sunt ca un caiet de sarcini clar, dar fără pagini în plus. Dacă proiectul vostru a început să semene cu un elefant într-un magazin de porțelan, poate e timpul să treceți la o dietă pe bază de protocoale?