الگوهای تاکتیکی که تا اینجا مورد بحث قرار گرفت،(راه‌های مختلف مدل‌سازی و پیاده‌سازی منطق تجاری بود) در این فصل، در یک زمینه گسترده راه های مختلف برای هماهنگ کردن تعاملات و وابستگی ها بین اجزای یک سیستم را بررسی خواهیم کرد

منطق تجاری در مقابل الگوهای طراحی:
منطق تجاری بخش مهمی از یک سیستم است اما همه آن نیست، برای اجرای الزامات کاربردی و غیر کاربردی پایگاه کد مسئولیتهای بیشتری را برعهده بگیرد. برای جمع‌آوری ورودی و ارائه خروجی باید با کاربران تعامل داشته باشد و باید از مکانیسم‌های ذخیره‌سازی مختلف برای تداوم وضعیت و ادغام با سیستم‌های خارجی و ارائه‌دهندگان اطلاعات استفاده کند. نگرانی‌های متنوع یک پایگاه کد منجر میشود که منطق تجاری در بین اجزای یک سیستم منتشر شود(در پایگاه داده، رابط کاربری یا حتی کپی کردن آن در بخش‌های مختلف) عدم سازماندهی کردن نگرانی‌های پیاده سازی، کار را در پایگاه کد سختتر میکند برای مثال هنگام تغییر منطق تجاری ممکن است مشخص نباشد دقیق کجا باید تغییر کند یا هنگام تغییر ممکن است جاهای مختلفی از کار بیافتد یا منجر به از دست رفتن کدهایی شود که نیاز به اصلاح داشتند. الگوهای معماری اصول سازمانی را برای جنبه‌های مختلف یک پایگاه کد معرفی می‌کنند و مرزهای واضحی را بین آنها ارائه می‌کنند: اینکه منطق تجاری چگونه به ورودی، خروجی و سایر اجزای زیرساختی سیستم متصل می‌شود که بر نحوه تعامل آنها اینکه چه دانشی را به اشتراک می‌گذارند و چگونه مولفه‌ها به یکدیگر ارجاع می‌کنند تاثیر می‌گذارد. انتخاب روش مناسب جهت سازماندهی پایگاه کد، یا الگوریتم معماری صحیح، برای حمایت از اجرای منطق تجاری در کوتاه مدت و کاهش تعمیر و نگهداری در بلند مدت بسیار مهم است. سه الگوی معماری کاربردی غالب شامل: معماری لایه‌ای، پورت‌ها و آداپتورها، CQRS رو باهم بررسی کنیم

معماری لایه‌ای:
یکی از رایجترین الگوهای معماری می‌باشد که پایکاه کد را در لایه‌های افقی سازماندهی می‌کند و هر لایه به یکی از نگرانی‌های فنی زیر می‌پردازد که شامل: تعامل با مصرف کنندگان(presentation layer)، منطق تجاری(business logic)، تداوم داده‌ها(data access layer) تصویر اول در کامنت‌ها
لایه تعامل که شامل رابط‌های ارتباطی است که می‌تواند gui,cli,restapi,webui باشد-لایه منطق تجاری که بصورت کپسوله شده است(قلب نرم افزار) الگوها و تصمیمات تجاری در آن است- لایه داده که شامل پایگاه داده است که شکل‌های مختلفی از قبیل پایگاه‌های sql,nosql در شکل های مختلفی از حافظه یا حتی اسناد و داکیومنت مانند باشد. ارتباط این لایه ها باهمدیگه از طریق یک کانال مستقیم از بالا به پایین و ترتیبی است بگونه‌ای که لایه تعامل هیچ درک و خبری از لایه تداوم داده ندارد

در معماری لایه‌ای مشاهده یک لایه اضافه معمول است
لایه سرویس:
لایه سرویس مرز یک برنامه را با لایه ای از خدمات تعریف می کند که مجموعه ای از عملیات موجود را ایجاد می کند و پاسخ برنامه را در هر عملیات هماهنگ می کند.( لایه سرویس به عنوان یک واسطه بین لایه های ارائه برنامه و منطق تجاری عمل می کند)

لایه سرویس در واقع یک مرز منطقی است نه یک سرویس فیزیکی، بعنوان یک نما برای منطق تجاری شناخته میشود که مرز لایه تعامل با منطق تجاری رو جدا میکنه،

داشتن یک لایه سرویس واضح چندین مزیت دارد:

• ما می توانیم از همان لایه سرویس برای سرویس دهی چندین رابط عمومی استفاده مجدد کنیم.

• با جمع آوری تمام روش های مرتبط در یک مکان، ماژولار بودن را بهبود می بخشد.

• لایه های ارائه و منطق تجاری را بیشتر جدا می کند.

• آزمایش عملکرد کسب و کار را آسان تر می کند.

یک لایه سرویس همیشه ضروری نیست. به عنوان مثال، زمانی که منطق کسب و کار به عنوان یک اسکریپت تراکنش پیاده‌سازی می‌شود، اساساً یک لایه سرویس است، زیرا قبلاً مجموعه‌ای از روش‌ها را که رابط عمومی سیستم را تشکیل می‌دهند، نشان می‌دهد

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

این مورد رو در ذهنتون نگه دارید:
همانگونه که استفاده از الگوهای طراحی بستگی به بزرگی و میزان پیچیدگی دارد، استفاده از لایه سرویس هم بستگی به الگوی طراحی مورد استفاده شده شما در سیستم دارد

اصطلاحات بکار برده شده

اصطلاحات دیگری که در معماری لایه‌ای استفاده می‌شوند:
• لایه ارائه = لایه رابط کاربر
• لایه سرویس = لایه برنامه
• لایه منطق تجاری = لایه دامنه = لایه مدل
• لایه دسترسی به داده = لایه زیرساخت

#DDD
#domain_driven_desigb

@code_crafters