خانه / OOP / مقدمه بر معماری و کتاب Clean Architecture

مقدمه بر معماری و کتاب Clean Architecture

مقدمه بر معماری و کتاب Clean Architecture

Uncle Bob

 

نام Uncle Bob را همگی با Clean Code و Clean Coder بخاطر داریم. که در این دو کتاب ارزشمند پرداخته می شود به کد و تولید کننده کد(دولوپر) خوب و با کیفیت. از Uncle Bob که تجربه ای به قدمت اولین خط کدهای برنام نویسی را دارند کتاب Clean Craftsmanship هم می توان نام برد.

از سری مجموعه کتاب های Clean آقای باب مارتین آخرین اثر ایشون کتاب Clean Architecture می باشد. که در این پست سعی می شود مختصری در باب Clean Architecture بیان شود که خواننده با اطلاعات و شناخت بیشتری به سراغ این کتاب برود.

——————————-

طی حدودا یک دهه گذشته افراد مختلف معماری های متفاوتی را جهت طراحی و پی ریزی نرم افزار و با هدف عمدتا ماژولاریزاسیون بهتر و مناسب تر را معرفی کردند. برخی از این معماریها بیشتر مورد توجه قرار گرفته و اقبال بیشتری داشتند و برخی نسبت به سایر معماریها کمتر.

به عنوان مثال میتوان به چند معماری زیر اشاره کرد:

  1. Hexagonal یا معماری Ports and Adapters که توسط Alistair Cockburnمعرفی شد.
  2. Onion Architecture توسط Jeffrey Palermo
  3. -Screaming Architecture توسط خود آقای باب مارتین

 

و موارد مشابه بسیار دیگر.

به هرکدام از این معماریها که نیک بنگریم علی رغم اینکه در جزییات پیاده سازی تفاوت های زیادی باهم دارند در پیاده سازی، در یک هدف اما همگی مشترک هستند، این معماریهایی که می توان همگی را به نوعی جز Hierarchical  Architecture و یا حتی با دیدی دیگر Layered Architecture(که البته با دیدگاه سنتی معماری لایه ای کاملا متفاوت می باشند( و یا Kernel Based Architecture محسوب نمود، و آنهم Separation of Concern   یا اصل SoC می باشد.یعنی بمنظورکمتر کردن tight coupling و رسیدن به cohesion   بیشتر سعی در جداسازی ماژولهایی دارند که کارهایی متفاوتی انجام می دهند. اصل ماژولاریزاسیون را اینجا میتوانید مشاهده بفرمایید.

Uncle Bob سعی کرد با بررسی و جمع آوری خصوصیات مشترک این معماری ها و با معرفی یک معماری جدید این معماری ها که همگی به دنبال هدف مشترکی بودند را در یک معماری جدید بنام Clean Architecture تجمیع کند.

از وجوه مشترک این سبک معماری ها که از برخی از آنها را در بالا نام برده شد، وجود دو لایه Business Roles   و Interfaces می باشد.

در گام نخست باب این دو لایه را در Clean Architecture قرار دادند که مختصرا در ادامه به توضیح آن خواهم پرداخت.

اما ببینیم سایر خصوصیات و مزایا این سبک از معماری ها کدام موارد هستند:

  1. اولین مورد بدون شک استقلال از معماری و سیستم های طراحی شده از Framework های مختلف می باشد. در این سیستم ها معماری ها به مثابه tools هستند و در صورت امکان بصورت plugin قابلیت استفاده دارند، اما به نوعی که هیچ وابستگی شدید بین سیستم با این tools ها وجود ندارد و براحتی قابلیت تعویض را دارا باشند.
  2. عدم وابسته بودن به هر نوع UI و Database ویژگی دیگر این معماری ها می باشد. در این معماری ها براحتی میتوان در صورت نیاز بدون تغییر Business Role ها UI موجود را تغییر دارد. همین داستان در مورد دیتابیس های مختلف نیز صادق است. تعویض از SQL Server به Oracle یا Mongo  و  BigTable براحتی انجام می شود.
  3. و مهمتر از همه استقلال کامل از دنیای بیرون می باشد. دنیای بیرون یعنی هر چیز و اتفاقی خارج از Business Role Layer که این لایه کاملا مستقل و بدون اطلاع از آنها طراحی و پیاده سازی می شود.

 

این تصویر معماری پیشنهادی آقای باب مارتین جهت تجمیع این موارد می باشد، که به توضیح مختصر بخش و لایه های آن در ادامه خواهم پرداخت.

اصل و قانون مهم وابستگی در Clean Architecture

اولین مورد قانون و اصلی وابستگی است که باید بین قسمت ها و لایه های مختلف وجود داشته و رعایت شده و دنبال شود. طبیعتا تخطی از اصول وضع شده برای هر سبک معماری باعث دور شدن از هدف اصلی وطبعا مزایای بر شمرده برای آن خواهد شد. قانون وابستگی در Clean Architecture شبیه به سایر معماری های مشابه می باشد. به زبان ساده واگرایی لایه هایی بیرونی به مرکز دایره این معماری که در تصویر بالا با عنوان Entities مشخص شده است. از سمت مرکز دایره به سمت بیرون که حرکت شود سطح انتزاع کمتر شده و بیشتر وارد جزییات پیاده سازی خواهیم شد. در واقع حرکت به سمت مرکز دایره باعث رسیدن به Policy های سیستم شده و حرکت در جهت عکس و به سمت بیرون ما را به گفته ی خود باب مارتین به مکانیزم ها خواهد رساند.

باب این rule را به این صورت بیان می کند:

The overriding rule that makes this architecture work is The Dependency Rule. This rule says that source code dependencies can only point inwards.

همانطور که در تصویر بالا ملاحظه فرمودید Clean Architecture شامل تعدادی دایره هم مرکز می باشد. آقای باب اشاره می کنند که تمام مواردی که در هردایره هستند در بی اطلاعی کامل از بیرون از دایره و محیط آن هستند. مثالی میزنم Entities در دایره زرد رنگ کوچک و به عنوان نقطه ی واگرایی سایر بخش ها هست. هر کلاس ماژول و قطعه کد درون این بخش هیچگونه اطلاع و طبعا وابستگی با دایره بیرونی یعنی Use Case ندارد. همانطور که احتمالا حدس زده اید این مورد بسیار شبیه مثلا دو سبک معماری نام آشنا تر یعنی Hexagonal  و Onion می باشد!.

در این مورد این جمله از آقای باب هم می تواند بیانگر همین موضوع باشد:

Nothing in an inner circle can know anything at all about something in an outer circle. In particular, the name of something declared in an outer circle must not be mentioned by the code in an inner circle. That includes, functions, classes. variables, or any other named software entity.

در این مورد همچنین ایشون اشاره می کنند که فرمت دیتا در لایه های بیرونی بخصوص اگر مربوط به فریمورک خارجی باشد نباید بر لایه ها و دایره های داخلی تاثیر گذار باشد. همان کاری که مثلا Adaptor ها در Hexagonal  انجام می دهند. هدف از بین بردن تاثیر لایه ها و دایره ها و دنیای بیرون بر دایره های داخلی که Business role  ها را شامل می شود. خوب بدیهی و مشخص است که حفظ Business role ها و از بین بردن وابستگی آنها با بیرون مهمترین و اصلی ترین هدفی است که دنبال می شود. چرا که اصولا برتری و مزیت رقابتی و تجاری و ارزش هر محصولی را همین Business role ها و نه فریمورک ها تعیین و مشخص می کنند.

 

در ادامه دایره ها و بخش های مختلف اون رو بررسی خواهم کرد. پس ادامه مقاله رو هم دنبال بفرمایید.

خوب از درونی ترین لایه شروع خواهم کرد. بخشی که گرایش و تمایل سایر بخش ها به آن سمت می باشد یعنی موجودیت ها.

Entities

باب موجودیت ها را این گونه تعریف می کند:

Entities encapsulate Enterprise wide business rules.

Entity میتونه کلاس یا آبجکتی باشه که دارای متد هم هست و میتونه هم فقط شامل ساختار خود موجودیت باشه. در این تعریف منظور از enterprise  اشاره به سیستم بزرگتری دارد که میتونه از sub system های یا application های مختلفی تشکیل شده باشد و در نتیجه این موجودیت ها میتونه و ممکن توسط سیستم های مختلف و متفاوتی مورد استفاده باشه. باب اشاره میکنه که اینکه چه تعداد سیستم مختلف ممکن است از یک entity  استفاده کند اصلا مهم نیست. باید گفت که Entity ها در واقع همان Domain Entity ها هستند در DDD.

Use Cases

در این لایه business role های مختص به هر application پیاده سازی خواهد شد. این business role هم در واقع همان use case و قوانین تعاملات کاربر نهایی با سیستم می باشد. این use case ها به مثابه هدایت کننده جریان داده به/از entity ها عمل می کنند. این لایه نباید هیچ تاثیری در state مربوط به entities  داشته باشد. کار این لایه صرفا orchestrate کردن جریان داده به/از موجودیت ها بر اساس قوانین بیزینس و use case ها می باشد. از طرف دیگر موارد خارجی از جمله UI یا Database نیز نباید تغییری بر لایه Use Case ها داشته باشد.

و البته طبیعی است که همانطور که باب هم اشاره می کنند؛ تغییرات در عملیات هر application منجر به تغییر use case های مربوط به اون عملیات شده و در نتیجه تغییراتی را در این لایه منجر خواهد شد.

 

Interface Adapters

این لایه دقیقا مشابه Adapterها در Hexagonal هستند. وظیفه این لایه تبدیل کردن دیتا  قابل استفاده در لایه های use case  و entities  به فرمت دیتای قابل استفاده توسط external tools ها از جمله data base  و موارد مشابه، و البته تبدیل بر عکس؛ می باشد. دیتایی که در این لایه رد و بدل می شود غالبا ساختار داده های ساده و بدون متد و بیزینس هستند. دیتا معمولا از controller به سمت entities و از entities توسط presenter به external tools ها مبادله می شود.

Similarly, data is converted, in this layer, from the form most convenient for entities and use cases, into the form most convenient for whatever persistence framework is being used. i.e. The Database.

 

Frameworks and Drivers

خوب رسیدیم به بیرونی ترین لایه. این لایه شامل معمولا data base ها؛ فریمورک ها؛ tools ها و موارد مشابه می باشد. جزییات اصلی کار ما اینجا هست و اینجا پیاده سازی خواهد شد. جزییات یعنی پیاده سازی ui یعنی کدهای sql یعنی در صورت استفاده از ابزار خارجی پیاده کد جهت استفاده از آن. باب تمام این موارد را به بیرونی ترین لایه منتقل کرد.

خوب تا اینجا دایره های موجود در تصویر بالا توضیح داده شد. در ادامه چند نکته کوتاه بیان خواهد شد در مورد Clean Architecture.

نکته ی اول اینکه تعداد چهار دایره بالا یک الزام یا Rule صد در صد نیست. این فقط یک ایده بود. و می توان بسته به نیاز و نوع سیستم تعداد دایره ها افزایش پیدا کند. چیزی که مهم می باشد و باید رعایت شود Dependency rule  و حفظ و رعایت آن می باشد. با حرکت  به سمت داخل سطح انتزاع افزایش پیدا خواهد کرد. و دایره های بیرونی شامل جزییات پیاده سازی بیشتری هستند.

نکته ی دوم: همانطور که توی راهنمای سمت راست تصویر مشاهده می کنید، جریان کنترل و حرکت بین دایره ها مشخص شده است. با دقت توی این بخش مشاهده خواهیم کرد که جریان همیشه از controller  شروع شده و به Entities می رود و سپس از طریق  Presenter به سمت بیرون حرکت می کند. همانطور که احتمالا حدس زده باشید؛ یک وابستگی بین Controller و Use Case و Use Case و Presenter بوجود می آید در این حالت. اما در بالا به صراحت بیان شده که مثلا در لایه ی Use Case نباید هیچ اسم و نامی از موارد موجود در لایه Adaptor آورده شود. نقض Dependency Role. خوب در این حالت Dependency Inversion Principal به کمک خواهد آمد. در این حالت مثلا Use Case می تواند یک Interface را صدا زده و استفاده کند و سپس این Interface در Presenter این اینترفیس implement شود.

نکته ی بعد در مورد دیتایی هست که بین دایره های بالا رد و بدل می شود. خوب این دیتا می تواند به طروق مختلفی از لایه ای به لایه دیگر برود. مثلا می تواند به عنوان پارامتر ورودی متدها یا سازنده ی کلاس استفاده شود. می تواند خود یک کلاس یا struct ساده باشد؛ به عبارتی همان DTO ها. باب بیان می کند که ما در اینجا قصد نداریم که مثلا یک Entity یا یک sql data row را بین مرزهای دایره ها رد و بدل کنیم. مثالی را به اینصورت بیان می کنند.

اکثر فریمورک های دیتابیس معمولا پس از گرفتن کوئری یک ساختار داده خاص برمی گردانند. مثلا data row یا data table و موارد مشابه. ارسال این ساختار داده به use case یا entities یا موارد مشابه باعث violate شدن Business Role خواهد شد. چرا که دایره داخلی و درونی در این حالت باید از ساختار داده این فریمورک دیتابیس اطلاع و آگاهی داشته باشد.

نتیجه گیری:

خوب تا به اینجا احتمالا ایده ی اولیه ای از Clean Architecture و البته معماری های مشابه بدست آورده اید. طبیعتا این معماری هم یک Silver bullet نیست و در کنار مزایای ملموس و غیر ملموس زیادی که دارد دارای مشکلات و سختی هایی هم خواهد بود. در اینجا قصد بر شمردن مزایا و معایب و یا مقایسه آن با سایر معماری ها را نداشتیم. هدف در اینجا فقط یک معرفی اولیه از این سبک معماری بود جزییات بسیار بیشتری از بخش ها و قواعد و پیاده سازی این معماری در کتاب Clean Architecture وجود دارد؛ که می توانید به این کتاب ارزشمند مراجعه بفرمائید.

 

درباره ی masoud@admin

همچنین ببینید

مقایسه سه Pattern مهم مشتق شده از MV* بنام MVC و MVP و MVVM

مقایسه سه Pattern مهم مشتق شده از MV* بنام MVC و MVP و MVVM MVC …

Tell Don’t Ask Principal

#Tell_Dont_Ask_Principal #OOP #اندکی_تامل ✍✍✍✍✍✍✍✍✍✍✍ یکی از اصول بسیار مهم در دنیای Object-Oriented اصل بسیار مهم …

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

در تلگرام هم همراه شما هستم

اگر علاقمند به معماری نرم افزار و مبحث محبوب مایکروسرویس هستید؛ در کانال با ما همراه باشید. اطلاعات مفید زیادی در این کانال انتظار شما را می کشند. فقط کافیست دکمه ی پیوستن را بفشارید.

پیوستن بستن