اغلب معماری های مورد استفاده در فرآیند تولید نرم افزار با چالش هایی در رابطه با Tight coupling یا مواردی مغایر با اصل Separation of concerns روبرو می شوند.معماری پیازی (Onion Architecture) که توسط جفری پارلمو (Jeffery Palermo) ارائه شده شرایط بهتری برای نگهداری ، سازماندهی وابستگی ها و تست یک اپلیکیشن را فراهم میکند.
اصول معماری پیازی
در معماری پیازی مانند معماری های n-tier یک نرم افزار از لایه های مختلفی تشکیل شده است، با این تفاوت که در این معماری لایه ها بصورت متحد المرکز با مرکزیت لایه هسته سیستم (Core Layer) که دامین مدل سیستم را تعریف و مشخص میکند ، مدل می شوند. در این معماری بر خلاف معماری چند لایه وابستگی به لایه دیتا وجود ندارد و تمرکز بر دامین اپلیکشن است.
مسائل و راه حل های ارائه شده
در معماری چند لایه قدیمی، ارتباط و وابستگی لایه ها از لایه رابط کاربری(User interface) به لایه بیزینس یا همان لایه قوانین و منطق های اپلیکیشن(Business layer) و از این لایه به لایه دیتا(Data Access) برقرار است، بنحوی که وابستگی بین لایه ها بشکل خیلی قوی دیده می شود و (Tight Coupling) بین لایه ها وجود دارد. بعبارت دیگر هیچکدام از دیگری مستقل نیستند. چنین وضعیتی موجب می شود که درک چنین سیستمهایی مشکل و نگهداری آنها نیز بمراتبط سخت تر وپرهزینه باشد.
در معماری پیازی برای حل این مشکل علاوه بر تعریف دامین سیستم، رفتار ها و نیازمندی های سیستم هم با استفاده از اینترفیس ها در لایه هسته سیستم (Core Layer) تعریف می شوند. البته این نوع تعریف اینترفیس ها برای معرفی کردن وابستگی ها در لایه های دیگر سیستم هم کاربرد دارد و فقط مختص به لایه Core نیست .در واقع هر لایه ای همانطور که قبلا هم گفته شد برای ارتباط با لایه های دیگر از اینترفیس ها استفاده میکند نه بصورت مستقیم از پیاده سازی انجام شده برای وابستگی ها.
لایه ها در معماری پیازی
اگر چه در این معماری نیز مفهوم لایه تعریف کننده ارتباط مفهومی اجزای تشکیل دهنده سیستم است، اما تعریف متفاوتی از معماری چند لایه (n-tier)، برای مفهموم لایه مورد بحث است.
لایه دامین(Domain layer)
در مرکز لایه های معماری پیازی لایه Core یا هسته سیستم ، لایه ای است که تعاریف بیزینس و رفتار های سیستم در آن مدل می شود. ایده اصلی این است که تمامی دامین آبجکت های اپلیکیشن در این لایه بنحوی که بدون وابستگی سخت (Hard dependency) باشند.
لایه اپلیکیشن(Application Layer)
لایه اپلیکیشن در بر گیرنده عملیاتی است که قوانین بیزینس ایجاب میکند که روی انتیتی های سیستم صورت پذیرد. بعنوان مثال عملیات ذخیره اطلاعات مشتری.سوالی که در اینجا پیش می آید این است که ذخیره اطلاعات عملیاتی است که با مکانیزم های ذخیره و بازیابی اطلاعات مرتبط است و همانطور که صحبت شد هدف از این معماری حذف وابستگی ها و از بین بردن Tight coupling است. بنابر این دیتابیس و جزییات نحوه ذخیره اطلاعات باید از قوانین بیزینس سیستم جدا باشند.
لایه ذخیره سازی(Persistence layer)
در این لایه نحوه ذخیره سازی اطلاعات سیستم ازلحاظ تکنولوژی مورد استفاده برای ارتباط با دیتابیس و نوع دیتابیس تعریف میشوند. به لایه ذخیره سازی می شود بعنوان یک پلاگین برای سیستم نگاه کرد. در حقیقت این اطلاعات است که برای سیستم ارزش دارد نه نحوه ذخیره سازی آنها. ذخیره اطلاعات می تواند به هر نحوی باشد در یک فایل متنی ،دیتابیس رابطه ای، No SQL دیتابیس و... . ارتباط بین لایه ذخیره سازی و لایه اپلیکیشن از طریق تزریق وابستگی ها با استفاده از اینترفیس های تعریف شده در لایه دامین سیستم ایجاد می شود.
لایه رابط کاربری(Presentation/User interface layer)
لایه رابط کاربری در حقیقت بیرونی ترین لایه معماری پیازی است. این لایه می تواند یک اپلیکیشن وب، یک Web API یا هر قابلیتی که امکان استفاده از بیزینس سیستم را بدهد باشد. عدم وجود وابستگی به پیاده سازی ها و استفاده از Dependency Injection باعث میشود که ارتباط با لایه های داخلی تر سیستم از طریق اینترفیس ها صورت پذیرد.
مزایا
محدویدیت ها و چالش ها
جمع بندی
استفاده از معماری پیازی باعث می شود که بتوان قوانین و حیاتی و مهم یک اپلیکیشن را از وابستگی های خارجی که عموما تکنیکال هستند جدا کرد. اگر گره خوردگی بین قوانین بیزینس اپلیکیشن و تکنولوژی های مورد استفاده وجود نداشته باشد مدیریت تکنولوژی ها استفاده شده بدون نگرانی از تاثیرات آن ها روی عملکرد سیستم آسان تر انجام می شود.
