مسئله‌ی اصلی: کجا سرویس را قطع کنیم؟
سخت‌ترین بخش طراحی میکروسرویس، تصمیم‌گیری درباره‌ی مرز هر سرویس است. تقسیم اشتباه (مثلاً تقسیم بر اساس لایه‌های فنی مثل «سرویس دیتابیس» و «سرویس رابط کاربری») باعث می‌شود سرویس‌ها به‌شدت به هم وابسته باشند و هر تغییر کوچک نیاز به هماهنگی چند سرویس داشته باشد؛ دقیقاً همان مشکلی که میکروسرویس قرار بود حل کند.
Domain-Driven Design (DDD) رویکردی است که پیشنهاد می‌کند سرویس‌ها را بر اساس مرزهای کسب‌وکاری تقسیم کنیم، نه لایه‌های فنی. ایده‌ی اصلی این است که با متخصصان کسب‌وکار صحبت کنیم و زبان و مفاهیمی که آن‌ها استفاده می‌کنند («سفارش»، «موجودی انبار»، «پرداخت») را به‌عنوان مبنای طراحی سرویس‌ها قرار دهیم؛ به این زبان مشترک، زبان فراگیر (Ubiquitous Language) گفته می‌شود.
مثال عملی: فروشگاه آنلاین
برای یک فروشگاه آنلاین، به‌جای تقسیم فنی، می‌توانیم بر اساس حوزه‌های کسب‌وکاری تقسیم کنیم:
- سرویس کاتالوگ: مدیریت محصولات، دسته‌بندی و قیمت.
- سرویس سفارش: ثبت و پیگیری سفارش‌های مشتری.
- سرویس موجودی: مدیریت انبار و رزرو کالا.
- سرویس پرداخت: ارتباط با درگاه‌های پرداخت.
هر یک از این سرویس‌ها یک مسئولیت کسب‌وکاری روشن و نسبتاً مستقل دارد و تیم مسئول آن می‌تواند بدون نیاز به هماهنگی دائمی با تیم‌های دیگر، روی آن کار کند.