معماری Onion
این معماری اولین بار توسط Jeffry Palermo در سال 2008 ارائه شد و ایده اصلی این معماری این بود که لایه‌های Domain و Core را در مرکز برنامه خود قرار داده و لایه هایی چون فریم‌ورک، database و تست را به خارج انتقال دهیم!
یکی از مهم‌ترین مفاهیمی که این معماری به آن اشاره دارد، مفهوم وارونگی وابستگی (Dependency Inversion) است. بر همین اساس بر خلاف معماری‌های بالا به پایین (Top-down)، دیتابیس مرکز ساختار پروژه ما را تشکیل نمی‌دهد و همیشه آن را در لایه‌ای خارجی خواهیم داشت. بیرون بردن database از معماری اصلی می‌تواند ساختار ذهنی برخی افراد را که به نرم‌افزارها به عنوان برنامه‌ای بر پایه database فکر می‌کنند، کاملاً تغییر دهد. در این معماری، بنای نرم‌افزار ما بر روی هیچ دیتابیس یا فریم‌ورکی ساخته نمی‌شود و در یک نرم‌افزار به یک پایگاه داده صرفا به عنوان یک سرویس ذخیره‌سازی نگاه می‌کنیم. باید توجه داشت که جدا کردن برنامه از پایگاه داده، سیستم فایل و غیره، تنها از طریق یک زیرساخت خارجی که با استفاده از interfaceها پیاده‌سازی شده است منطقی است. هسته برنامه وظیفه پیاده‌سازی رابط‌های اصلی را دارد، و کلاس‌هایی که قرار است از این interfaceها استفاده کنند، در لبه‌های برنامه قرار خواهد داشت، از این رو ما به مکانیزمی برای تزریق کد در زمان اجرا نیاز داریم تا برنامه بتواند کار مفیدی انجام دهد. بنابراین فقط لایه‌های بیرونی به رابط‌های لایه‌های داخلی وابستگی دارند و لایه های داخلی هیچ گونه وابستگی به لایه‌های بیرونی نخواهند داشت. همچنین مسیر حرکت در این معماری از UI شروع شده و تا Domain ادامه خواهد داشت. با توجه به این نکته، اهمیت دارد که تمام وابستگی‌ها به سمت داخل حرکت کنند.
قدرتی که این معماری به ما می‌دهد در این است که ما اکنون این انعطاف‌پذیری را خواهیم داشت که لایه‌های بیرونی را بدون تأثیرگذاری بر هیچ یک از لایه‌های داخلی تغییر دهیم. مثلا در نظر داشته باشید اگر بخواهیم پیاده‌سازی زیرساخت ارسال ایمیل را تغییر دهیم، تنها کافی است از interfaceهای تعریف‌شده توسط core استفاده کنیم. حتی با در نظر گرفتن پیاده‌سازی موجود در core پروژه، امکان تغییر framework را نیز به سادگی خواهیم داشت.
بیایید لایه‌های مختلف این معماری را بررسی کنیم:
اگر لایه بیرونی را با infrastructure ،presentation و test جدا کنیم، لایه داخلی (هسته برنامه) همچنان باید بتواند بدون لایه‌های بیرونی اجرا شود.
بنابراین با به کارگیری ایده‌های این معماری، می‌توانیم تکرار و وابستگی به لایه‌هایی مثل دیتابیس، فریم‌ورک و غیره را کاهش دهیم. همه این‌ها به ما کمک خواهد کرد تا تست‌پذیری و قابلیت نگهداری سیستم‌ها را بهبود ببخشیم.
در نتیجه مواردی که بعد از پیاده‌سازی معماری onion خواهیم داشت:
هسته برنامه (application core) را می‌توان از outer layerها جدا کرد و همچنان یک هسته فعال داشته باشیم.
این پست ادامه دارد ...
منابع بخش دوم:
clean architecture book
ThinkToCode
با تشکر از :
K.Akbari
