common architecture
hexagonal
یکی از معماری هایی که آنکل باب با استفاده از این ، معماری کلین رو پیشنهاد می کنه
در این معماری ، تمرکز بیشتر روی جداسازی ( Dependency injection ) منطق برنامه از ابزار و فریم ورک است .
در این معماری یک هسته ی مرکزی داریم که بخش اصلی این معماری است و در صورتی که بخواهیم ابزار ها را تغییر دهیم ، این رویکرد به ما این امکان را می دهد که هسته را به صورت مجزا آزمایش کنیم و به ما این امکان را می دهد که به راحتی اجزای زیرساخت را تغییر دهیم
این بخش به نام core که در آن ۳ زیر بخش داریم :
دامین domain ( entity ) که همان موجودیت های ماست ، مانند معماری کلین
پورت ports، در حقیقت وظیفه ی جدا سازی را دارد و اینترفیس ها را تعریف می کنیم که ارتباط بازیگران ( actors ) را مشخص می کند
سرویس ها services - نقاط ورود ما به هسته هستند و هر یک از آنها با استفاده از پورت ها ( اینترفیس ها) منطق برنامه را پیاده سازی می کنند ( بیزینس لاجیک ) - به عبارت دیگر متد های اینترفیس را با استفاده از تایپ امبدینگ ، استفاده می کنیم -
حال که موجودیت ( دامین ) و پورت ها ( اینترفیس ها ) و منطق بیزینسمان ( سرویس ها ) را مشخص کردیم ، هسته ی برنامه را کامل کردیم ، حال باید آداپتور های برنامه را پیاده سازی کنیم - به عبارت دیگر اینترفیس ها را امپلمنت کنیم
آداپتور ها
آداپتور ها در حقیقت استراکت های کانکریت شده با توجه به پورت ها هستند
آداپتور ها دو دسته اند
درایور ها یا آداپتور اصلی ( پرایمری ) - این کلاس ها در خواست های بیرونی را هندل کرده و در حقیقت باعث شروع عملیات می شوند مانند درخواست های شبکه یا http - cli
( بهتر است در آداپتور و پوشه ای به نام هندل باشد )
-
دریون ها یا آداپتور ثانویه ( سکندری ) - این کلاس ها نیاز های بیزینس به ابزار های بک اندی را پیاده سازی می کند مانند متد هایی که برای ارتباط با دیتا بیس نیاز است ( بهتر است در آداپتور و پوشه ای به نام ریپازیتوری باشد )
https://medium.com/@matiasvarela/hexagonal-architecture-in-go-cfd4e436faa3
onion arch
این معماری تمرکزش بیشتر روی لایه لایه بندی برنامست و این که هر لایه به لایه درونی وابسته باشد و لایه درونی بی نیاز و ومستقل از لایه بیرونی باشه
clean arch
و اما این معماری ترکیبی از 2 معماری بالاست
Application Service Orchestration
گاهی یه سری نیاز مندی ها داریم که بین لایه ای هستن
مثلا اگر یه trigger و یا cronjob از لایه httpcall فعال بشه و باید تاثیر روی لایه repository بزاره ، نباید وابستگی ها رو تغییر بدیم مثلا http calll دسترسی به repository بزاره - اینجا یه لایه اپلیکیشن داریم که یه سری ارتباطات بین لایه ای رو مدیریت می کنه
همچنین گاهی باید یه ترنس اکشن برای چندین متد repository باشه و این ترنس اکشن باید یه لایه بالا تر از usecase باشه این هم تو لایه ی اپلیکیشن هست
بهترین practice این است که در لایه‌ی domain یک UseCase تعریف شود و لایه‌ی پایین‌تر (مثل Exchange یا HTTP) فقط آن interface را صدا بزند. Business logic در UseCase اجرا می‌شود و از طریق repository interface با data layer صحبت می‌کند. اگر رفتار async نیاز باشد، از channel داخل application/service layer استفاده شود. این روش ساده، تست‌پذیر و کاملاً منطبق با Clean Architecture است و از over-engineering جلوگیری می‌کند.
tips
تفاوت Scheduler و Job زمانی که می خواهیم لایه ی WORKER اضافه کنیم
-
Scheduler → decides WHEN something runs
-
Job (task) → defines WHAT runs