در این حالت backend servicesهای جداگانه ایجاد کنید تا توسط frontend applications یا 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 خود میدهد. برای اطلاعات بیشتر دیدن این لینک توصیه می شود.
مسائل و ملاحظات:
چه زمانی از این الگو استفاده کنیم؟
این الگو در حالتهای زیر مناسب نیست: