architecture

انواع معماری

• monolitic arch
• microservice arch
• event driven arch
• Hexagonal Architecture (Ports and Adapters)
• N-Tier Architecture
• onion Architecture
• Service-Oriented Architecture (SOA)
• client server arch

diff SOA vs microservice

• communication

در حالی که در میکروسرویس سرویس ها میتونن از طریق http (rest , soap) و یا مسیج صحبت کنند . soa از Enterprise Service Bus (ESB) استفاده می کند و به این معنی است که یه سرویس این وسط هست که این سرویس ها رو مدیریت می کنه - توجه شود به طور معمول از kafka استفاده نمی کنند

ویژگی	Microservices	SOA
اندازه سرویس‌ها	سرویس‌ها خیلی کوچک و متمرکز روی یک قابلیت مشخص هستند.	سرویس‌ها بزرگ‌تر و ممکنه چند قابلیت مرتبط رو در یک سرویس داشته باشند.
ارتباط بین سرویس‌ها	معمولاً سبک (Lightweight) و با REST, gRPC, Messaging	معمولاً با Enterprise Service Bus (ESB) یا پروتکل‌های سنگین‌تر مثل SOAP
استقلال استقرار	هر سرویس جداگانه Deploy و Scale می‌شود.	معمولاً سرویس‌ها وابستگی بیشتری دارند و استقرار مستقل سخت‌تر است.
پشتیبانی از فناوری متفاوت	هر سرویس می‌تواند با زبان و دیتابیس متفاوت پیاده شود.	معمولاً از یک فناوری اصلی یا محدودیت‌های سازمانی تبعیت می‌کند.
تمرکز طراحی	تمرکز بر استقلال کامل هر سرویس.	تمرکز بر اشتراک‌گذاری قابلیت‌ها بین سرویس‌ها.
دیتابیس	دیتابیس مشترک هست.	هر سرویس دیتابیس خودش رو داره.
انعطاف‌پذیری	بالا، اما نیازمند پیچیدگی بیشتر در DevOps و مانیتورینگ.	ساده‌تر از نظر عملیاتی ولی انعطاف کمتر دارد.

diff n-tier vs onion

توی پیاز تست نویسی راحت تره چون مرکز دامین هست اما توی n-tier مرکز دیتابیس هست و وابستگی به دیتابیس خیلی بالاست

usecase

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

این لایه باید جوری باشه که حتی کسی که زبان برنامه نویسی ما رو بلد نیست هم متوجه بشه

در این بخش ولیدیت ابتدایی داده یا یا بخش های خیلی سطح پایین برنامه نباید باشه تنها منطق و لاجیک اون کار

ورودی و خروجی باید یا entity باشه یا DTO اگر ورودی از استراکت به بایت تغییر کرد , usecase ما تغییر نمی کنه چون فقط منطق اون تو هست

در صورتی این لایه تغییر می کنه که منطق برنامه تغییر کنه ـ نه به دیتا بیس ارتباط داره ، نه به پروتوکل های داده نه به کانورت ساختار ورودی و خروجی

همچنین نباید بخشی از منطق در آداپتور باشه بخشی در کنترلر ، منطق سراسر در یوزکیس هست

controller

interface

بهترین نام گذاری فوادر برای این پروتوکل یا کانترکت است

contracts 
protocol

repository pattern

یه design pattern هست که می گه کوییری باید از لاجیک جدا بشه و تمامی کوییری ها -crud - باید در یه لایه باشد و در لایه لاجیک تنها اونها کال بشن و با خواندن یوز کیس ، مشخص نباشه نوع دیتابیس یا متن کوییری ها .

ما همیشه از این دیزاین استفاده می کنیم بدون اینکه بفهمیم

Clean Architecture Directory/Layers

Entities: Represent the core business objects.

Use Cases/Interactors: Contain the application-specific business logic.

Interfaces/Adapters: Act as a bridge between the core application and the external systems.

Frameworks/Drivers: Include all external dependencies and infrastructure-related code.

متفرقه

• Redundancy اطلاعات تکراری شاید در چند جا ذخیره بشن و مدیریت آن در چند جا سخت میشه

• Stateless Services سرویس داده ذخیره یا سشنی نداره و استیت در صورتی که داره باید بقیه ذخیره کنن

• Rate Limiting تعداد درخواست ها رو کنترل میکنیم مثل استفاده از timeframe

metadata

اطلاعاتی مانند message IDs, timestamps, message routing information, correlation IDs دارد و طبیعتن جزو داده هایی برایusecase نیستن ولی این داده ها برا موارد زیر نیاز است :

توجه شود به هیچ وجه نباید کاربر دخالتی در تولید metadata داشته باشند ، تنها gateway, authorizer باید این بخش را ولید کنند

• کاربرد ها

• • Security

با فرض اینکه کار شاید بتپاند اطلاعات payload را خود ایجاد کند ولی اطلاعات metadata را بهتر است authorizer پر کند ، در این حال در صورتی که سرویس نیاز به دابل چک داشته باشد می توان به داده های metadata اطمینان کند

• • Monitoring and Logging

بهترین داده برای لاگگینگ و مانیتور کردن و ترک کردن data flow در میکرو سرویس

• • Message Routing

می تونه کمک کنه برای مشخص کردن اینکه مسیج ها چگونه بین سرویس ها جابجا شوند

• استفاده در clean architecture

متا دیتا چون در بیزینس لاجیک نیست ، بهتره در controller / interactor مدیریت شود ، در حقیقت در مکانی که ولید بودن در خواست چک شود

scope architecture - building blocks

namespace

برای دسته بندی کردن و مرتب کردن کد های طوری که در اسم گذادی ها کانفلیکت نخوریم ، این مفهوم بیشتر در c , c++ , java کاربرد دارد

همچنین وقتی صحبت در اسکوپ namespace می شه منظور در مقیاس یا دسترسی کلاس ها ، فانکشن ها و وریبل های یک ماژول صحبت میشه

ماژول

برای سازمان دهی فانکشن ها همچنین برای ری یوزبل کردن آنها که می توان در یک یا چند فایل بیان ، که از کلاس ها ، فانکشن ها و مقدار ها ساخته شده

پکیج

برای سازماندهی و مدیریت ارتباط چند ماژول است ، پکیج می توان چند ماژول یا ساب پکیج در خود داشته باشد

لایبری

کد هایی از پیش نوشته شده هستند که می توان در پروژه ها استفاده نمود ، تمرکز لایبری ، ارتباط آسان و فراهم کردن فانکشن یا توضیحات برای راحت سازی و استفاده در پروژه های متنوع است لیبری می توان به صورت تنها باشد یا در یک پکیج استفاده شود

توجه شود این شاید درست یا کامل نباشد

اگر بخواهیم یک سیستمرو بریکداون کنیم یعنی بشکونیم و از کوچیک به بزرگ تقسیم کنیم ، میشه ترتیب زیر

• functions , method

کوچیک ترینبخش برای اجرای تسک یا اوپریشن

• class, object

چندین فانکشن یک کلاس رو میسازن و یک رفتار یا یک قابلییت رو نمایش میده

• component

کامپوننت ها ماژولار هستند ، همچنین مستقل هستند و اینکپسول ارتباط داده ها و لاجیک درون خود شده اند ، می توان چندین بار مجددن استفاده کرد - reusable - و نگهداری آن به دلیل اینکه جدایی پذیر است راحته

• module , library

قابل نسخه بندی و ورژن بندی میباشند

• service

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

• subsystem

• application

• system, architecture

• framework

یه چارچوب هست که ساختار برنامه رو محدود می کنه و برای جریان برنامه راه مشخصی داره

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

• library

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

• platform

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