از مالکیت شروع کنید، نه endpoint
هر سرویس باید یک قابلیت منسجم و داده‌های مربوط به آن را مالک باشد. تبدیل هر موجودیت به یک سرویس مستقل، ممکن است یک عملیات ساده کسب‌وکار را به زنجیره فراخوانی راه دور تبدیل کند. در این حالت کد توزیع شده، اما منطق همچنان به‌شدت وابسته است.
بپرسید چه بخشی می‌تواند قانون را تغییر دهد، قواعد در کجا تضمین می‌شوند و کدام داده‌ها باید همزمان سازگار بمانند. این پرسش‌ها از شمردن کنترلر یا جدول مفیدترند.
هزینه تغییر را بررسی کنید
اگر تغییر معمولی به انتشار هماهنگ چند سرویس نیاز دارد، بررسی کنید آیا مرز از میان یک قابلیت عبور کرده است. نوشتن مشترک در پایگاه داده و زنجیره طولانی فراخوانی همزمان، نشانه‌های قابل بررسی هستند؛ نه اثبات خودکار اشتباه بودن Microservices.
شروع با یکپارچه ماژولار می‌تواند تصمیم درستی باشد. ماژول‌های روشن و مالکیت مشخص نشان می‌دهند مرز شبکه در آینده کجا مناسب است.
مرز را اعتبارسنجی کنید
یک جریان کامل را همراه اعتبارسنجی، خطا و تلاش مجدد دنبال کنید. مشخص کنید هر تصمیم را کدام سرویس می‌گیرد و هنگام قطع وابستگی چه اتفاقی می‌افتد. از قرارداد صریح استفاده کنید، نه دسترسی مستقیم به پایگاه داده سرویس دیگر.
هدف، امکان فهم مستقل و تغییر قابل مدیریت است. افزایش تعداد سرویس‌ها به‌خودی‌خود نتیجه معماری نیست.
منبع برای مطالعه بیشتر
مستندات و استاندارد مرجع