هر میکروسرویسی باید پایگاه‌داده‌ی مخصوص و خصوصی خود را داشته باشد و دیگر میکروسرویس‌ها تنها اجازه‌ی استفاده از واسط کاربری (API + Events) آن را خواهند داشت.

در صورت استفاده از تعداد زیادی میکروسرویس حتما باید از فرآیند CI/CD استفاده کنیم.

روش دیکتاتور گونه‌ی معمار نرم‌افزار منسوخ شده و دیگر نباید یک معمار تنها مانند یک رییس معماری را به صورت سند بر تیم توسعه تحمیل کند. این جریان نباید یکطرفه بوده بلکه باید همواره معمار بازخورد تصمیمات خود را دریافت کرده و مشکلات آن را حس کند، بدین منظور یک معمار نرم‌افزار باید دارای مهارت‌های نرم بسیاری باشد.

در رویکرد Domain Driven Design (DDD)، توسعه‌دهندگان با متخصصان دامنه کسب و کار آشنا میشوند و نامگذاری کلاسها و توابع بر اساس دامنه حوزه کسب و کار انجام میشود. این رویکرد ارتباطات بهتر بین توسعه‌دهندگان و متخصصان دامنه را تسهیل میکند و انعطافپذیری بیشتر در برابر تغییرات و قابلیت نگهداری بیشتر را ارائه میدهد.

عنصر اول Enabling Team: تیم‌هایی که به سایر تیم‌ها ابزارها، خدمات و ساختارهای لازم را فراهم می‌کنند تا به سرعت و با کیفیت به توسعه و ارائه محصولات بپردازند.
عنصر دوم Complicated Subsystem Team: تیم‌هایی که مسئولیت دارند زیرساخت‌ها و زیرسیستم‌های پیچیده‌تر را توسعه و حفظ کنند.
عنصر سوم Stream-aligned Team: تیم‌هایی که به طور مستقیم با خط تولید و ارائه محصول در ارتباط هستند و مسئولیت ارائه و توسعه محصولات خاصی را برعهده دارند.
عنصر چهارم Complicated Subsystem Team with Enabling Team: تیم‌هایی که هم زیرسیستم‌های پیچیده را توسعه می‌دهند و هم به سایر تیم‌ها ابزارها و خدماتی را ارائه می‌دهند