الگوهای طراحی و معماری-2

Domain Logic

Domain Model – بخش اول :

منظور از اين مدل، object modelي از دامنه مساله است که هر کلاس آن شامل رفتار و ساختار موجوديتي(Entity) از موجوديتهاي آن دامنه است، براي مثال، "سند حسابداري"، که از مجموعه اي از آرتيکلها، تاريخ، شماره عنوان و وضعيت ساخته مي شود، از سويي مي تواند متد يا رفتاري با نام BALANCE را در خود داشته باشد که تراز بودن آن را مشخص مي کند، يادآوري مي کنم در روشي مانند Transaction Script متدي در يک کلاس که تراکنش ثبت سند را انجام مي دهد وجود دارد که تراز بودن سند را بررسي مي کند در حالي که در الگوي حاضر اين متد درون خود کلاس سند قرار مي گيرد.

نمودار Domain Model ، شبيه به نمودار Database Model است،با اين تفاوت که در آن موجوديتها علاوه بر ساختار، داراي رفتار و پروسس بوده و در مدل، شبکه اي پيچيده از ارتباطات (Association)بين اشيا و رابطه ارث بري (Inheritance) بين آنها وجود دارد.

خلاصه اينکه Domain Model متشکل از شبکه اي از اشيا به هم مرتبط از موجوديتهاي دامنه مساله است، هر موجوديت در دامنه مساله فارغ از سايز و اندازه اش و پيچيدگيش، داراي معناي خاص و واضحي است براي مثال "شرکت" موجوديتي بزرگ و "سفارش خريد" موجوديتي کوچک در دامنه مساله سيستم "پيگيري سفارشات" است که هر دو در مدل، کلاسهايي نظير براي خود دارند. بديهي است استفاده از Domain Model در يک برنامه به معناي قرار دادن تمام شبکه اشياء ساخته شده براي مساله در آن دامنه است، پس بهتر است از همين ابتدا ذکر کنم که خيال کندن بخشي از يک مدل و قرار دادن آن د برنامه اي ديگر را از ذهنتان بيرون کنيد، اين کار در ادامه پروژه تان به فاجعه منجر خواهد شد.

در مدل مورد بحث، ميتوان اشياء را به دو دسته تقسيم کرد، اشيايي که داراي ساختاري معادل با موجوديت هاي مساله هستند و اشيايي که تنها قوانين و آلگوريتمهاي محاسباتي مختلف را در خود دارند و به اقتضاي نيازهاي غير عملکردي در سيستم بوجود آمده اند، براي مثال مي توان به شي کارمند و احکام حقوقي او در سيستم حقوق دستمزد و شي محاسبه کننده کسورات بر اساس نوع بيمه کارمند اشاره کرد، دو شي اولي داراي ساختاري از اطلاعات دامنه مساله و دومي در برگيرنده آلگوريتمهاي محاسبه کسورات بر حسب نوع بيمه و قرارداد کارمند است. لازم به ذکر است که در الگوي Domain model اولويت با ترکيب الگوريتمها در کلاس نماينده موجوديتهاست و تنها بايد بر حسب ضرورتهاي طراحي و بر اساس الگوهاي طراحي نسبت به استخراج آلگوريتمها و محاسبات و قرار دادن آنها در کلاسهاي جداگانه اقدام کرد.

مدلهاي حاصل از اين الگو را مي توان به دو دسته ساده و پيچيده تقسيم کرد، در Domain Model هاي ساده به ازاي هر جدول در بانک اطلاعاتي يک کلاس در مدل وجود دارد؛ در مدلهاي پيچيده الازمي براي تطابق ساختار مدل با ساختار بانک اطلاعاتي وجود نداشته و درآن از ارث بري و الگوهاي طراحي به منظور خوانايي و انعطاف بيشتر استفاده مي شود. نگاشت مدلهاي ساده به بانک اطلاعاتي به سادگي و با استفاده از الگويي مانند Active Record انجام مي شود در حالي که نگاشت مدلهاي پيچيده مشکل تر بوده و نيازمند استفاده از Data Mapper ها ست .(در اين باب در پستهاي بعدي به تفصيل سخن خواهم گفت)

از آنجا که قوانين حاکم بر دامنه کسب و کار مرتبط با برنامه هاي ايجاده شده عموما در حال تغيير و تحول هستند لازم است براي جلوگيري از نشر و تاثير اين تغييرات در لايه هاي ديگر برنامه، حداقل وابستگي ممکن بين Domain Model و ساير لايه هاي برنامه وجود داشته باشد تا بتوان علاوه بر کنترل باز نشر تغييرات در ساير لايه ها، امکان Build و Test جداگانه Domain Model را نيز فراهم کرد.

مزايا:

زماني که از اين الگو براي ايجاد لايه Domain Logic استفاده مي کنيد، زبان مشترکي بين اعضاي تيم توليد وحتي مشتري، در حوزه مساله ايجاد مي شود که تعامل بين اين افراد را در پروژه ساده تر مي نمايد، با توجه به تطبيق فضاي راه حل با مساله- به علت وجود موجوديتهاي معادل دامنه در راه حل و برنامه- درک و فهم سيستم براي سايرين ساده تر شده، همپنين تقسيم وظايف لازم براي انجام يک کار بين اشيا به راحتي انجام مي گيريد. از سويي وجود اين خصوصيات خود موجب کاهش هزينه نگهداري سيستم در دراز مدت شده و با تغيير و پيچيده تر شدن مساله در طول زمان نگهداري و اعمال تغيير راحت تر از حالات ديگر خواهد بود.

معايب:

اين شيوه نياز به دانش بيشتري در حوزه طراحي و اصول و مفاهيم شي گرايي نسبت به ساير روشها داشته و نيازمند بکارگيري نيروهاي حرفه اي تر و متعاقبا گرانتري در انجام پروژه است، از سويي وجود لايه ها و کامپوننت هاي متعدد براي نگاشت موجوديتها به جداول بانک اطلاعاتي (Data Mappper) و DTO ها در صورت لزوم موجب افزايش زمان محاسبات ، استفاده از منابع بيشتر RAM و CPU مي شود.

چه زماني از اين روش استفاده کنيد:

زماني بايد ازالگوي Domain Model استفاده نمود که با مساله اي پيچيده مواجه هستيد، مساله اي که در آن تعداد زيادي آلگوريتم محاسباتي براي شرايط مختلف، الگوهاي متفاوت براي صحت سنجي اطلاعات و مجموعه اي از قوانين دائما در حال تغيير وجود دارد .

در پست بعد اين الگو با دقت و موشکافي بيشتري بررسي شده و در پست بعد از آن (شايد هم در هما همان پست)پياده سازي مساله اي کوچک را به اين شيوه و با استفاده از تکنولوژي .net و EF ارائه خواهم داد.

الگوهای طراحی و معماری-2

مطالب مشابه :

الگوهای طراحی و معماری-2

الگو های طراحی (Design Pattern)

الگوهای معماری(Architectual Patterns) -مدل های مرجع(Reference Models) - معماری های مرجع(Reference Ar

الگوهای طراحی، محاسن و معایب (Design Patterns Pros & Cons)

الگوهای طراحی(desing pattern)

برنامه نویسی شی گرا - Object Oriented Programming

بررسي و شناخت متدولوژي RUP

یک دوره آموزش کامل RUP

مهندسی نرم افزار

این طرح برنده مسابقه طراحی معماری اندونزی شد