برنامه نویسی

پیاده سازی طراحی دامنه محور – روز ششم

ما مجموعه خود را ادامه می دهیم، دوباره در فصل 4 درباره معماری
بریم 😆

الف. معماری شش ضلعی

آلیستر کاکبرن با معماری شش ضلعی، سبکی را برای ایجاد تقارن تدوین کرد. این هدف را با اجازه دادن به بسیاری از مشتریان متفاوت برای تعامل با سیستم در شرایط برابر پیش می برد. به مشتری جدید نیاز دارید؟ مشکلی نیست فقط یک آداپتور اضافه کنید تا ورودی هر مشتری داده شده را به ورودی قابل فهم توسط API برنامه داخلی تبدیل کنید. در عین حال، مکانیسم های خروجی به کار گرفته شده توسط سیستم، مانند گرافیک، تداوم، و پیام رسانی نیز ممکن است متنوع و قابل تعویض باشند. این ممکن است زیرا یک آداپتور برای تبدیل نتایج برنامه به فرمی که توسط یک مکانیزم خروجی خاص پذیرفته شده است ایجاد شده است.

معماری_هگزاگونال

ما معمولاً مکانی را که مشتریان با سیستم در تعامل هستند به عنوان “انتخاب” آن در نظر می گیریم. به همین ترتیب، ما مکانی را که برنامه در آن داده‌های ثابت را بازیابی می‌کند، داده‌های پایدار جدید را ذخیره می‌کند، یا خروجی ارسال می‌کند به عنوان «انتهای پشتیبان» در نظر می‌گیریم. اما شش ضلعی روش متفاوتی را برای نگاه کردن به نواحی یک سیستم ترویج می کند، همانطور که در شکل 4.4 نشان داده شده است. دو ناحیه اصلی وجود دارد، بیرون و داخل. بیرون مشتریان متفاوت را قادر می‌سازد ورودی ارسال کنند و همچنین مکانیسم‌هایی را برای بازیابی داده‌های باقی‌مانده، ذخیره خروجی برنامه (مثلاً پایگاه داده)، یا ارسال آن به جای دیگری در مسیر خود (مثلاً پیام‌رسانی) فراهم می‌کند.

هر نوع کلاینت آداپتور مخصوص به خود را دارد [Gamma et al.]، که
پروتکل‌های ورودی را به ورودی‌ای تبدیل می‌کند که با API برنامه – داخل آن سازگار است. هر یک از ضلع های شش ضلعی نشان دهنده نوع متفاوتی از پورت، برای ورودی یا خروجی است. سه درخواست مشتری از طریق یک پورت ورودی (آداپتورهای A، B و C) دریافت می‌شود و یکی از پورت‌های متفاوتی استفاده می‌کند.
(آداپتور D). شاید این سه از HTTP (مرورگر، REST، SOAP و غیره) استفاده کنند و یکی از AMQP (مثلا RabbitMQ). تعریف دقیقی از معنای بندر وجود ندارد و آن را به مفهومی انعطاف پذیر تبدیل می کند. به هر روشی که پورت ها پارتیشن بندی شوند، درخواست های مشتری می رسد و آداپتور مربوطه ورودی آنها را تغییر می دهد. سپس عملیاتی را روی برنامه فراخوانی می کند یا رویدادی را برای برنامه ارسال می کند. بنابراین کنترل به داخل منتقل می شود.

طرف دیگر برنامه، سمت راست چطور؟ پیاده سازی Repository را به عنوان آداپتورهای ماندگار در نظر بگیرید، که دسترسی به نمونه های Aggregate ذخیره شده قبلی و ذخیره سازی موارد جدید را فراهم می کند. همانطور که در نمودار نشان داده شده است (آداپتورهای E، F و G)، ممکن است پیاده‌سازی مخزن برای پایگاه‌های داده رابطه‌ای، ذخیره‌سازی اسناد، حافظه پنهان توزیع شده و ذخیره‌های درون حافظه داشته باشیم. اگر برنامه پیام‌های رویداد دامنه را به خارج ارسال کند، از آداپتور (H) دیگری برای پیام‌رسانی استفاده می‌کند. آداپتور پیام‌رسان خروجی برعکس آداپتور ورودی است که از AMQP پشتیبانی می‌کند و بنابراین پورتی متفاوت از پورت مورد استفاده برای ماندگاری خارج می‌شود.

ب. چرا معماری شش ضلعی؟

مزیت بزرگ Hexagonal این است که آداپتورها به راحتی برای اهداف آزمایشی توسعه داده می شوند. کل برنامه کاربردی و مدل دامنه را می توان قبل از وجود کلاینت ها و مکانیسم های ذخیره سازی طراحی و آزمایش کرد. قبل از اینکه تصمیمی برای پشتیبانی از HTTP/REST، SOAP یا پورت‌های پیام‌رسانی گرفته شود، می‌توان آزمایش‌هایی را برای اجرای ProductService ایجاد کرد. هر تعداد مشتری آزمایشی را می توان توسعه داد
قبل از تکمیل وایرفریم های رابط کاربری. مدت ها قبل از اینکه مکانیزم ماندگاری برای پروژه انتخاب شود، می توان از مخازن درون حافظه برای تقلید ماندگاری به منظور آزمایش استفاده کرد. برای جزئیات بیشتر در مورد توسعه پیاده سازی های درون حافظه به مخازن (12) مراجعه کنید. بدون نیاز به اجزای فنی تکمیلی می توان پیشرفت قابل توجهی در هسته ایجاد کرد. در صورت استفاده از لایه های واقعی، مزایای سرنگونی ساختار و توسعه بر اساس پورت ها و آداپتورها را در نظر بگیرید. هنگامی که به درستی طراحی شود، شش ضلعی داخل – مدل برنامه و دامنه – به قسمت های بیرونی نشت نمی کند. این یک مرز برنامه تمیز را در داخل که موارد استفاده در آن پیاده سازی می شود، ترویج می کند. خارج از هر تعداد آداپتور مشتری می تواند پشتیبانی کند
تست‌های خودکار متعدد و کلاینت‌های دنیای واقعی، و همچنین ذخیره‌سازی، پیام‌رسانی و سایر مکانیسم‌های خروجی.

ج. نتیجه گیری

از آنجایی که معماری شش ضلعی همه کاره است، می تواند پایه ای باشد که از دیگر معماری های مورد نیاز سیستم پشتیبانی می کند. به عنوان مثال، ما ممکن است خدمات محور، REST، یا یک معماری رویداد محور را در نظر بگیریم. سبک شش ضلعی پایه محکمی را برای پشتیبانی از هر یک از آن گزینه های معماری اضافی تشکیل می دهد.

ببینمت 😌

نوشته های مشابه

دیدگاهتان را بنویسید

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

دکمه بازگشت به بالا