در این حالت سرویس‌های backend جداگانه ایجاد کنید تا توسط اپلیکیشن‌های frontend یا interfaceهای خاص مصرف شود. این الگو زمانی مفید است که بخواهید از سفارشی‌سازی یک Backend برای چندین interface یا رابط کاربری اجتناب کنید. این الگو اولین‌بار توسط Sam Newman توصیف شد.
هدف‌گذاری تولید یک نرم‌افزار می‌تواند بر اساس یک رابط کاربری مبتنی بر desktop application
یا web ui باشد. معمولاً، یک سرویس backend به طور هم‌زمان با سرویس frontend توسعه می‌یابد که هر دوی این سرویس‌ها ویژگی‌های وابسته هم را ایجاد می‌کنند به‌طوری‌که اجرای صحیح یکی به دیگری وابسته است. همان‌طور که توسعه برنامه رشد می‌کند، نیازمندی‌هایی جدیدی به وجود می‌آید که در روزهای اولیه طراحی نرم‌افزار در نظر گرفته نشده بودند؛ مثلاً یک برنامه mobile application هم در کنار دو سرویس قبلی شروع به توسعه می‌کند که باید با همان Backend تعامل داشته باشد. سرویس Backend به یک Backend همه‌منظوره تبدیل می‌شود که باید نیازهای رابط desktop/web UI و تلفن همراه را برآورده کند.
اما قابلیت‌های یک دستگاه تلفن همراه از نظر اندازه صفحه‌نمایش، عملکرد و محدودیت‌های نمایش به طور قابل‌توجهی با یک مرورگر دسکتاپ متفاوت است. در نتیجه، الزامات یک برنامه mobile application با رابط کاربری desktop/web UI متفاوت است.
این تفاوت‌ها منجر به الزامات مختلفی برای backend می‌شود. سرویس backend نیاز به تغییرات منظم و قابل‌توجهی دارد تا هم به رابط کاربری وب دسکتاپ و هم به اپلیکیشن تلفن همراه ارائه شود. اغلب، تیم‌های رابط جداگانه روی هر فرانت‌اند (تلفن همراه و وب) کار می‌کنند و باعث می‌شوند که backend به گلوگاهی در فرایند توسعه تبدیل شود. الزامات به‌روزرسانی متناقض، و نیاز به کارکردن سرویس برای هر دو فرانت‌اند، می‌تواند منجر به‌صرف تلاش زیادی برای سرویس backend شود.
ازآنجایی‌که فعالیت توسعه بر روی سرویس Backend متمرکز است، ممکن است یک تیم جداگانه برای مدیریت و نگهداری Backend ایجاد شود. در نهایت، این منجر به قطع ارتباط بین تیم‌های توسعه رابط کاربری و Backend می‌شود و باری را بر دوش تیم Backend می‌گذارد تا بین نیازهای رقابتی تیم‌های مختلف UI تعادل برقرار کند. هنگامی که یک تیم frontend به تغییراتی در Backend نیاز دارد، این تغییرات باید قبل از اینکه بتوان آنها را در Backend ادغام کرد، با سایر تیم‌های frontend در mobile/web UI هماهنگ شود.
برای هر رابط کاربری یک backend ایجاد کنید. رفتار و عملکرد هر backend را طوری تنظیم کنید که به بهترین وجه با نیازهای frontend مطابقت داشته باشد، بدون اینکه نگران تأثیرگذاری بر سایر frontendهای دیگر باشید.
ازآنجایی‌که هر backend مخصوص یک frontend است، می‌توان آن را برای آن frontend بهینه کرد. در نتیجه، کوچک‌تر، پیچیده‌تر و احتمالاً سریع‌تر از یک Backend همه‌کاره است که سعی می‌کند الزامات همه frontendها در mobile/web UI را برآورده کند. هر تیم رابط برای کنترل Backend خود استقلال دارد و به یک تیم توسعه بک‌اند متمرکز متکی نیست. این به تیم frontend انعطاف‌پذیری در انتخاب زبان، آهنگ انتشار، اولویت‌بندی حجم کار و یکپارچه‌سازی ویژگی‌ها در Backend خود می‌دهد. برای اطلاعات بیشتر دیدن این لینک توصیه می‌شود.
- در نظر بگیرید که چه تعداد Backend باید مستقر کنید.
- اگر frontendهای مختلف (مانند کلاینت‌های تلفن همراه) درخواست‌های یکسانی ارائه می‌دهند، در نظر بگیرید که آیا لازم است یک Backend برای هر frontend پیاده‌سازی شود یا اینکه یک Backend واحد کافی است. - هنگام پیاده‌سازی این الگو، احتمال تکرار کد در بین سرویس‌ها بسیار زیاد است.
- همین‌طور backend services متمرکز بر frontend فقط باید logic و behavior مربوط به client-specific را پیاده‌سازی کند. منطق business logic و سایر خصوصیات سراسری (global features) باید در جای دیگری از برنامه مدیریت شوند.
- به این فکر کنید که چگونه این الگو ممکن است در مسئولیت‌های یک تیم توسعه منعکس شود و تأثیرگذار باشد.
- در نظر بگیرید که اجرای این الگو چقدر طول می‌کشد و هزینه زمانی ایجاد می‌کند. آیا تلاش برای ساخت بک‌اندهای جدید بدهی فنی بیشتری را به همراه دارد نسبت به حالت یک backend همه‌منظوره؟
- یک سرویس backend مشترک یا همه‌منظوره باید با سربار و مشکلات قابل‌توجهی هنگام توسعه حفظ شود.
- شما می‌خواهید backend را برای نیازهای frontendهای خاص یا ویژه بهینه کنید.
- سفارشی‌سازی‌ها در یک backend همه‌منظوره برای تطبیق چندین frontend مختلف.
این الگو در حالت‌های زیر مناسب نیست:
- هنگامی که frontendها requestهای مشابهی را به backend ارسال و دریافت می‌کنند.
- زمانی که تنها از یک frontend برای تعامل با backend استفاده می‌شود.