01
معماری
در معماری Microservices، هر سرویس از طریق پایگاه داده مستقل، مالک داده‌های خود است. کلاینت‌ها به‌جای وابستگی مستقیم به تک‌تک سرویس‌های داخلی از API Gateway وارد می‌شوند. مرزها بر اساس قابلیت‌های کسب‌وکار تعریف می‌شوند و ارتباط با API و پیام‌های مشخص شکل می‌گیرد.
02
پیام‌رسانی
RabbitMQ و MassTransit امکان ارتباط رویدادمحور را فراهم می‌کنند. رویدادها تغییرات را میان مرز سرویس‌ها منتقل می‌کنند. مصرف‌کننده باید تحویل تکراری و خطا را صریح مدیریت کند؛ بنابراین پیام‌رسانی علاوه بر انتخاب ابزار انتقال، مسئله قابلیت اعتماد است.
03
ارتباط بین سرویس‌ها
gRPC برای قراردادهای همزمانی مناسب است که پاسخ آن‌ها در همان عملیات لازم است. پیام‌رسانی غیرهمزمان برای کارهایی به کار می‌رود که می‌توانند مستقل پیش بروند. نیاز به سازگاری داده، تأخیر و رفتار هنگام در دسترس نبودن سرویس مقابل، در این انتخاب نقش دارند.
04
معماری محصول و فروشنده
سرویس Product به‌جای خواندن مستقیم پایگاه داده Seller، یک SupplierReadModel محلی نگه می‌دارد. به این ترتیب مالکیت داده فروشنده حفظ می‌شود و Product می‌تواند پرس‌وجوهای خودش را پاسخ دهد. این مدل، نمایی از اطلاعات مورد نیاز محصول است و منبع اصلی تازه‌ای برای داده فروشنده محسوب نمی‌شود.