Microservices एक संगठनात्मक निर्णय जति नै तकनीकी निर्णय हो। Conway's law ले भन्छ कि प्रणालीहरू ती बनाउने संगठनको संचार संरचनालाई प्रतिबिम्बित गर्छन् — त्यसैले तपाईंको टीम संरचनाले तपाईंको आर्किटेक्चरलाई आकार दिन्छ चाहे तपाई यसको योजना गरी या नगरी।
"Organizations design systems that copy their communication structure."
3 teams that don't talk → 3 services with awkward, accidental seams
→ Inverse Conway Maneuver: design TEAMS around the architecture you want
प्रत्येक सेवाको स्पष्ट मालिक टीम हुनुपर्छ जसले यसलाई बनाउँछ, तैनाथ गर्छ, र संचालन गर्छ ("तपाई यसलाई बनाउनुहुन्छ, तपाई यसलाई चलाउनुहुन्छ")। साझा स्वामित्वले उपेक्षित सेवाहरू निर्माण गर्छ।
Orders team ─owns─▶ Orders service (code + deploy + on-call)
Payments team ─owns─▶ Payments service
→ autonomy: each team ships without waiting on others
| टीम प्रकार | भूमिका |
|---|---|
| Stream-aligned | उत्पादनको एक टुक्रालाई स्वामित्व गर्छ (अधिकांश टीमहरू) |
| Platform | स्व-सेवा आधारभूत ढांचा प्रदान गर्छ (CI/CD, mesh) |
| Enabling | अन्य टीमहरूलाई अभ्यासमा प्रशिक्षण दिन्छ |
| Complicated-subsystem | गहिरो विशेषीकृत क्षेत्रको स्वामित्व गर्छ |
लक्ष्य क्रस-टीम संज्ञानात्मक भार र हस्तान्तरणलाई न्यूनतम गर्नु हो।
टीमहरूलाई पुनर्संरचित नगरी microservices अपनाएमा वितरित monolith उत्पन्न हुन्छ, किनभने पुरानो समन्वय ढाँचाहरू आर्किटेक्चरमा लोप हुन्छन्।
यदि टीमहरूले एक सुविधा पठाउन निरन्तर समन्वय गर्नुपर्छ भने, आर्किटेक्चरले त्यो युग्मनलाई प्रतिबिम्बित गर्दछ चाहे तपाई सेवा रेखाचित्रलाई कति स्वच्छ रूपमा कोर्नुहुन्छ।
टीम सीमानाहरूलाई सेवा सीमानाहरूसँग पङ्क्तिबद्ध गर्नु (inverse Conway maneuver) वास्तवमा microservices ले वचन गरेको स्वायत्तता र स्वतन्त्र-तैनाथ लाभहरूलाई प्रदान गर्छ — संगठन चार्ट डिजाइनको एक अংश हो।