Mohamad Wiki - User contributions [en-gb]

اینترنت چیست و چگونه کار میکند؟

2026-09-10T18:22:17Z

Mkaravi: اینترنت چیست و چگونه کار میکند

<div dir="rtl" style="text-align: right; line-height: 1.8;">

__TOC__

= اینترنت چیست و چگونه کار می‌کند؟ (راهنمای جامع معماری شبکه) =

'''اینترنت''' (The Internet) شبکهٔ شبکه‌هاست؛ سامانه‌ای جهانی، توزیع‌شده و مستقل از میلیاردها دستگاه محاسباتی که از طریق مجموعه‌ای از پروتکل‌های باز و استاندارد بین‌المللی ارتباط برقرار می‌کنند. هیچ فرد، شرکت، دولت یا نهاد مرکزی واحدی مالک اینترنت نیست یا آن را به تنهایی کنترل نمی‌کند. قدرت اصلی اینترنت در معماری نامتمرکز آن و استفاده از زبان‌های استاندارد مشترکی به نام '''پروتکل (Protocol)''' نهفته است.

بین اینترنت و وب تفاوت اساسی وجود دارد:
* '''اینترنت (Internet):''' زیرساخت فیزیکی، سخت‌افزاری و پروتکل‌های لایه‌پایین ارتباطی بین دستگاه‌ها.
* '''وب جهان‌گستر (World Wide Web):''' سامانه‌ای از صفحات چندرسانه‌ای و اسناد متنی به‌هم‌پیوسته که به عنوان یکی از چندین سرویس روی بستر اینترنت فعالیت می‌کند (مشابه ایمیل یا انتقال فایل).

----

== ۱. لایهٔ فیزیکی و فیزیک انتقال داده (Wires, Cables & Wi-Fi) ==

اساسی‌ترین واحد اطلاعات در دنیای دیجیتال، '''بیت (Bit)''' است که نشان‌دهندهٔ وضعیت دوگانه (صفر یا یک / روشن یا خاموش) است. تمام متن‌ها، عکس‌ها، ویدیوها و دستورات به رشته‌هایی از بیت‌ها تبدیل شده و سپس از طریق رسانه‌های فیزیکی هدایت می‌شوند.

=== روش‌های انتقال فیزیکی بیت‌ها ===

# '''الکتریسیته (کابل‌های اترنت مسی و کواکسیال):'''
#* '''مکانیسم:''' با تغییر سطح ولتاژ الکتریکی ارسال می‌شود (مثلاً ولتاژ بالا معادل عدد ۱ و ولتاژ پایین معادل عدد ۰).
#* '''مزایا:''' هزینه پایین، زیرساخت در دسترس و سیم‌کشی آسان درون ساختمان‌ها و شبکه‌های محلی (LAN).
#* '''چالش‌ها:''' دچار افت شدید سیگنال بر اثر مقاومت در مسافت‌های طولانی شده و نسبت به امواج الکترومغناطیسی محیط آسیب‌پذیر است.
# '''نور (فیبرهای نوری - Fiber Optic):'''
#* '''مکانیسم:''' بیت‌ها به پالس‌های نوری فوق‌سریع درون رشته‌های شیشه‌ای بسیار باریک تبدیل می‌شوند و به لطف پدیده «بازتاب کلی داخلی نور» (Total Internal Reflection) درون هسته کابل به جلو حرکت می‌کنند.
#* '''مزایا:''' بالاترین پهنای باند ممکن در فواصل قاره‌ای بدون افت چشمگیر کیفیت؛ زیرساخت اصلی کف اقیانوس‌ها که قاره‌ها را به یکدیگر وصل می‌کند بر پایه فیبر نوری است.
#* '''چالش‌ها:''' فرآیند تولید حساس، آسیب‌پذیری فیزیکی در صورت خم شدن بیش‌ازحد و هزینه‌های بالای جوش فیبر (Splicing).
# '''امواج رادیویی (وای‌فای و شبکه‌های تلفن همراه):'''
#* '''مکانیسم:''' بیت‌ها روی امواج رادیویی با فرکانس مشخص سوار شده و به‌صورت بی‌سیم تابش می‌شوند. در سمت دریافت‌کننده، کارت شبکه مجدداً امواج را به صفر و یک تبدیل می‌کند.
#* '''مزایا:''' تحرک‌پذیری بالا (Mobility) و دسترسی آسان در خانه‌ها، دفاتر و دستگاه‌های قابل حمل.
#* '''چالش‌ها:''' محدوده پوشش جغرافیایی کوتاه، افت سیگنال در اثر عبور از دیوارها، موانع فیزیکی و شرایط جوی.

{| class="wikitable" style="margin: 1em auto; text-align: center;"
! نوع رسانه !! مکانیزم انتقال !! مسافت پوشش !! پهنای باند و سرعت
|-
| '''کابل مسی (LAN)''' || پالس ولتاژ الکتریکی || کوتاه (کمتر از ۱۰۰ متر) || متوسط تا بالا
|-
| '''فیبر نوری''' || پالس‌های نور لیزری || بسیار طولانی (هزاران کیلومتر) || فوق‌العاده بالا
|-
| '''امواج رادیویی (Wi-Fi)''' || فرکانس‌های رادیویی || کوتاه تا متوسط (چند ده متر) || متوسط (بسته به فاصله)
|}

----

== ۲. شناسایی و مسیریابی دستگاه‌ها: پروتکل IP و سامانه DNS ==

در شبکه‌ای با میلیاردها گره، هر فرستنده باید دقیقاً بداند پیام خود را به چه مقصدی ارسال می‌کند.

=== پروتکل اینترنت (Internet Protocol - IP) ===
آدرس IP یک شناسهٔ یکتای عددی برای هر دستگاه متصل به شبکه است.

* '''استاندارد IPv4:'''
** ساختار ۳۲ بیتی متشکل از چهار عدد بین ۰ تا ۲۵۵ که با نقطه از هم جدا می‌شوند:
** <div dir="ltr" style="text-align: left; display: inline-block;"><code>192.168.1.1</code> یا <code>172.217.16.206</code></div>
** این فرمت حدود ۴٫۳ میلیارد آدرس ارائه می‌دهد که با رشد اینترنت و دستگاه‌های IoT به اتمام رسیده است.
* '''استاندارد IPv6:'''
** ساختار ۱۲۸ بیتی با نمادهای هگزادسیمال که توسط دونقطه تفکیک می‌شوند:
** <div dir="ltr" style="text-align: left; display: inline-block;"><code>2001:0db8:85a3:0000:0000:8a2e:0370:7334</code></div>
** این فضا توانایی تولید <div dir="ltr" style="text-align: left; display: inline-block;"><code>3.4 × 10<sup>38</sup></code></div> آدرس یکتا را داراست.

=== سامانه نام دامنه (Domain Name System - DNS) ===
حفظ کردن آدرس‌های عددی برای انسان ناممکن است. سامانهٔ DNS نقش دفترچه تلفن اینترنت را ایفا کرده و نام‌های انسان‌خوان (مانند <div dir="ltr" style="text-align: left; display: inline-block;"><code>wikipedia.org</code></div>) را به آدرس‌های عددی ماشین‌خوان (مانند <div dir="ltr" style="text-align: left; display: inline-block;"><code>208.80.154.224</code></div>) تبدیل می‌کند.

'''مراحل سلسله‌مراتبی حل نام دامنه (DNS Resolution):'''
# '''بررسی حافظه نهان (Local Cache):''' مرورگر یا سیستم‌عامل ابتدا کش محلی خود را بررسی می‌کند.
# '''سرور حل‌کننده محلی (Recursive DNS Resolver):''' از سوی ISP یا سرویس‌دهندگانی مانند Cloudflare (1.1.1.1) یا Google (8.8.8.8) استعلام می‌شود.
# '''سرور ریشه (Root Server):''' پایگاه‌های اصلی که درخواست را به سرورهای پسوند دامنه هدایت می‌کنند.
# '''سرور TLD (Top-Level Domain):''' مدیریت پسوندهایی نظیر <code>.com</code>، <code>.org</code> یا <code>.ir</code>.
# '''سرور نام معتبر (Authoritative Name Server):''' نگه‌دارنده رکورد نهایی که آدرس IP دقیق دامنه را برمی‌گرداند.

----

== ۳. بسته‌ها، مسیریابی و قابلیت اطمینان (Packets, Routing & TCP) ==

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

=== ۱. بسته‌بندی داده‌ها (Packet Switching) ===
قبل از ارسال، داده‌ها به قطعات کوچکی به نام '''بسته (Packet)''' تقسیم می‌شوند. هر بسته شامل دو بخش است:
* '''سربار (Header):''' شامل آدرس IP فرستنده، آدرس IP مقصد، اندازه بسته، شماره ردیف و پروتکل.
* '''بدنه (Payload):''' خودِ تکه دیتای اصلی (مانند بخشی از کد یک تصویر یا پیام).

=== ۲. مسیریابی و روترها (Routers) ===
روترها کامپیوترهای تخصصی مدیریت ترافیک هستند.
* هیچ بسته الزاماً مسیری یکسان با بسته دیگر را طی نمی‌کند.
* اگر یک کابل در اقیانوس پاره شود یا روتری دچار بار ترافیکی شدید گردد، روترها مسیر جدیدی از بین گره‌های دیگر به صورت پویا و خودکار انتخاب می‌کنند (Fault Tolerance).

=== ۳. پروتکل تضمین تحویل داده (TCP vs. UDP) ===

* '''پروتکل TCP (Transmission Control Protocol):'''
** تضمین‌کنندهٔ ترتیب و رسیدن صددرصدی بسته‌ها به مقصد.
** قبل از انتقال با استفاده از مکانیسم دست‌تکانی سه مرحله‌ای (<div dir="ltr" style="text-align: left; display: inline-block;"><code>3-Way Handshake: SYN -> SYN-ACK -> ACK</code></div>) اتصال پایدار برقرار می‌کند.
** اگر بسته‌ای در میان راه گم شود، TCP متوجه غیبت آن شده و از فرستنده درخواست ارسال مجدد می‌کند. پس از دریافت کامل، بسته‌ها بر اساس شماره ترتیب بازچینی می‌شوند.
* '''پروتکل UDP (User Datagram Protocol):'''
** پروتکلی سریع و بدون تضمین رسیدن و بدون ایجاد اتصال اولیه. بسته‌ها ارسال می‌شوند بدون این که بررسی شود آیا رسیده‌اند یا خیر.
** ''کاربرد:'' بازی‌های آنلاین (Online Gaming)، استریم‌های زنده ویدیویی و تماس‌های اینترنتی (VoIP) که سرعت نسبت به از دست رفتن چند فریم اولویت دارد.

----

== ۴. وب و لایهٔ کاربرد: HTTP و HTML ==

در بالاترین لایه، استانداردهایی برای ارتباط نرم‌افزاری کاربر با سرویس‌ها وجود دارد:

=== پروتکل انتقال ابرمتن (HTTP / HTTPS) ===
زبان ارتباطی مرورگر (کلاینت) با سرویس‌دهنده وب (وب‌سرور):
* '''درخواست‌های کلاینت (HTTP Requests):'''
** متد <div dir="ltr" style="text-align: left; display: inline-block;"><code>GET</code></div>: برای مطالبه و دریافت داده‌ها از سرور.
** متد <div dir="ltr" style="text-align: left; display: inline-block;"><code>POST</code></div>: برای ارسال داده‌ها (مانند رمز عبور یا فایل) به سرور.
* '''پاسخ‌های سرور (HTTP Status Codes):'''
** <div dir="ltr" style="text-align: left; display: inline-block;"><code>200 OK</code></div>: درخواست با موفقیت پردازش شد.
** <div dir="ltr" style="text-align: left; display: inline-block;"><code>404 Not Found</code></div>: منبع درخواستی روی سرور وجود ندارد.
** <div dir="ltr" style="text-align: left; display: inline-block;"><code>500 Internal Server Error</code></div>: سرور دچار خطای داخلی شده است.

=== زبان نشانه‌گذاری HTML ===
کدهای متنی ساختاریافته با تگ‌ها که اسکلت صفحات وب را می‌سازند. مرورگر متن‌های دریافت شده را به همراه کدهای CSS (استایل ظاهری) و JavaScript (منطق عملکردی) به یک صفحه بصری قابل درک رندر می‌کند.

----

== ۵. امنیت، رمزنگاری و کلیدهای نامتقارن (Cryptography & SSL/TLS) ==

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

=== انواع روش‌های رمزنگاری ===

# '''رمزنگاری متقارن (Symmetric Encryption):''' فرستنده و گیرنده از یک کلید مخفی یکسان برای رمزگذاری و رمزگشایی استفاده می‌کنند. اگر کلید حین تبادل لو برود، امنیت کاملاً از دست می‌رود.
# '''رمزنگاری نامتقارن / کلید عمومی (Public Key Cryptography):'''
#* '''کلید عمومی (Public Key):''' در دسترس همه قرار دارد و هر کس می‌تواند با آن پیامی را قفل و رمزگذاری کند.
#* '''کلید خصوصی (Private Key):''' فقط و فقط در اختیار مالک سرور است و تنها این کلید می‌تواند داده‌ای را که با کلید عمومی قفل شده باز کند.

=== پروتکل SSL / TLS و HTTPS ===
پروتکل <div dir="ltr" style="text-align: left; display: inline-block;"><code>HTTPS</code></div> نسخه‌ای امن از HTTP است که از لایهٔ امنیتی TLS بهره می‌برد:
# کلاینت به سرور متصل می‌شود و گواهی دیجیتال (SSL Certificate) معتبر سرور را درخواست می‌کند.
# هویت سرور توسط مراجع صدور گواهی (CA) تایید می‌شود.
# از طریق رمزنگاری نامتقارن، یک کلید متقارن موقت امن برای آن نشست تبادل می‌شود.
# تمام تبادلات داده‌ای بعدی با آن کلید موقت، کاملاً غیرقابل خواندن برای شنودگران (Sniffers) می‌شود.

----

== ۶. امنیت سایبری و تهدیدات متداول (Cybersecurity & Threats) ==

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

{| class="wikitable sortable" style="margin: 1em auto; width: 95%;"
! نوع تهدید !! نحوه عملکرد !! پیامد و خطرات !! تدابیر دفاعی
|-
| '''بدافزار و ویروس‌ها (Malware)''' || فایل‌ها یا اسکریپت‌های مخربی که مخفیانه اجرا می‌شوند. || سرقت اطلاعات محلی، تخریب سیستم‌عامل و جاسوسی. || استفاده از آنتی‌ویروس، اجرای نرم‌افزارها در محیط ایزوله و به‌روزرسانی سیستم.
|-
| '''فیشینگ (Phishing)''' || فریب کاربر از طریق ایمیل‌ها و صفحات وب‌سایت کاملاً مشابه نسخه‌های اصلی. || سرقت اطلاعات ورود، حساب‌های بانکی و جعل هویت. || بررسی دقیق URL، استفاده از مدیر رمز عبور و احراز هویت دومرحله‌ای (2FA).
|-
| '''حملات منع سرویس توزیع‌شده (DDoS)''' || ارتشی از دستگاه‌های آلوده (بات‌نت‌ها) ترافیک عظیمی را همزمان به سمت یک سرور سرازیر می‌کنند. || پر شدن پهنای باند سرور و خارج شدن سایت از دسترس عموم. || شبکه توزیع محتوا (CDN)، فایروال‌های لایه وب (WAF) و فیلترینگ ترافیک.
|-
| '''حمله مرد میانی (MitM)''' || هکر در مسیر ارتباطی کلاینت و سرور قرار گرفته و تبادل داده را شنود یا دستکاری می‌کند. || سرقت کوکی‌های ورود، رمزها و اطلاعات هویتی. || استفاده اجباری از پروتکل HTTPS و خودداری از شبکه‌های عمومی ناامن Wi-Fi.
|}

----

== جمع‌بندی لایه‌های ارتباطی ==

مدل کلی اینترنت را می‌توان به ۴ لایهٔ کاربردی خلاصه کرد:

<div dir="ltr" style="text-align: left; background: #f8f9fa; border: 1px solid #a2a9b1; padding: 12px; margin: 1em 0; border-radius: 4px; font-family: monospace;">
[ 4. Application Layer ] ---> HTTP, HTTPS, DNS, FTP, SMTP<br />
[ 3. Transport Layer ] ---> TCP (Reliable), UDP (Fast)<br />
[ 2. Internet Layer ] ---> IP (Addressing & Routing - IPv4 / IPv6)<br />
[ 1. Network Interface ] ---> Ethernet, Wi-Fi, Fiber Optic, Radio Waves
</div>

----

== پیوندهای مرتبط و منابع ==
* [https://roadmap.sh/guides/what-is-internet راهنمای اصلی How does the internet work در Roadmap.sh]
* [https://code.org/curriculum/unplugged مجموعه مستندهای ویدیویی آموزش اینترنت از Code.org]
* [https://howdns.works آموزش تصویری تعاملی سامانه نام دامنه (How DNS Works)]

[[رده:اینترنت]]
[[رده:شبکه‌های رایانه‌ای]]
[[رده:پروتکل‌های اینترنت]]
[[رده:امنیت شبکه]]

</div>

Modular-Monolith-with-DDD

2026-09-02T08:50:47Z

Mkaravi: Modular Monolith with DDD

================================================================================
MODULAR MONOLITH WITH DOMAIN-DRIVEN DESIGN (DDD)
Comprehensive Repository & Architecture Review (kgrzybek/modular-monolith-with-ddd)
================================================================================

[ENGLISH SECTION - LTR]
================================================================================

1. INTRODUCTION & PURPOSE OF THE REPOSITORY
--------------------------------------------------------------------------------
The repository "kgrzybek/modular-monolith-with-ddd" by Kamil Grzybek is widely
regarded as one of the definitive architectural references in the software engineering
community. It bridges the gap between traditional monolithic systems and distributed
microservice architectures.

Key Objectives:
* Demonstrating how to design and build a maintainable, extensible enterprise .NET
application using a Modular Monolith architecture.
* Realizing the benefits of microservices (clear bounded contexts, domain autonomy,
independent data schemas, team boundaries) without taking on operational
complexities (network latency, distributed transaction coordination, eventual consistency
headaches, and heavy CI/CD infrastructure).
* Providing a production-ready, non-trivial application reference rather than a basic
proof of concept (PoC).
* Implementing Domain-Driven Design (DDD) tactical patterns and Testable Design principles.

2. DOMAIN DESCRIPTION: MEETUP PLATFORM
--------------------------------------------------------------------------------
The application models a comprehensive real-world domain: an event/meeting management
platform similar to Meetup.com.

Domain Concepts & Business Rules:
* Meeting Groups: Members can propose new meeting groups. Each group proposal requires
administrative review and approval before becoming active.
* Subscriptions: Each Meeting Group must have an Organizer with an active subscription.
A single subscription covers up to 3 Meeting Groups.
* Meetings: Only an Organizer of an active Meeting Group can create meetings. A meeting
has attendees, non-attendees (members explicitly declining), and a waitlist.
* Quotas & Limits: Meetings can enforce attendee limits. When the limit is reached, new
sign-ups automatically queue into the waitlist.
* Roles: Attendees can hold roles (Attendee or Host). Every meeting requires at least
one Host who has privileges to modify meeting details and attendee rosters.
* Event Fees & Guests: Organizers can configure mandatory event fees. Attendees can invite
guests if allowed, paying the required fees on behalf of their guests.
* Comments: Members can write comments, reply to existing comments, and like comments,
governed by meeting configuration rules.

3. ARCHITECTURAL BLUEPRINT & C4 MODEL STRUCTURE
--------------------------------------------------------------------------------
The repository employs Simon Brown's C4 model (System Context, Container, Component,
and Code) documented via PlantUML (diagrams-as-code).

The architecture consists of the following distinct modules / bounded contexts:

1. API (Host Container):
- Ultra-thin ASP.NET Core Web API layer.
- Responsibilities: accept HTTP requests, delegate authentication/authorization
via the UserAccess module, dispatch commands and queries to internal modules,
and return HTTP responses.
- Contains ZERO business or application logic.

2. UserAccess Module:
- Manages user identity, registration validation, authentication, JWT token issuance,
roles, and fine-grained permissions.

3. Registrations Module:
- Handles the user onboarding pipeline: registration requests, confirmation email
flows, and registration verification state machines.

4. Meetings Module (Core Domain):
- The heart of the business domain: creation and lifecycle of Meeting Groups, Meetings,
Attendees, Waitlists, and Comment threads.

5. Administration Module:
- Dedicated workflows for back-office administrators: reviewing, approving, or
rejecting meeting group proposals and auditing platform policies.

6. Payments Module:
- Financial workflows: subscription fee payments, event entry fees, payer records,
and payment confirmation state handling.

4. TACTICAL DDD PATTERNS & INTERNAL MODULE ANATOMY
--------------------------------------------------------------------------------
Each module is designed with strict boundaries and zero unauthorized coupling:

* High Level of Encapsulation:
All internal domain entities, repository implementations, command handlers, and
database models are marked with C# 'internal' access modifiers. External callers
only interact with a very small, public facade interface (e.g., IMeetingsModule).

* Rich Domain Models (Persistence Ignorance):
Domain entities are pure POCOs without EF Core or infrastructure dependencies. All
business invariants and rules are strictly encapsulated inside Aggregate Roots.

* Combating Primitive Obsession:
Strong Value Objects are used throughout (e.g., MeetingId, MemberId, Money,
MeetingLimits) instead of raw strings, integers, or GUIDs.

* CQRS (Command Query Responsibility Segregation):
- Command Pipeline (Write): Domain-driven mutation handled through MediatR/handlers
and Entity Framework Core with strict repository patterns.
- Query Pipeline (Read): High-performance, read-only SQL queries projected directly
into DTOs using Dapper, completely bypassing domain models and change tracking.

* Asynchronous Inter-Module Communication:
Modules NEVER make direct database calls or synchronous method invocations across
module boundaries. Inter-module communication is 100% asynchronous, mediated by an
Event Bus.

* Reliability: Transactional Outbox & Inbox Patterns:
- Outbox Pattern: Integration events are saved into an Outbox table within the SAME
local database transaction that mutates aggregate state. A background worker
(Quartz.NET) polls the Outbox and dispatches events to the in-memory event bus.
- Inbox Pattern: Receiving modules store incoming messages into an Inbox table to
guarantee exactly/at-least-once processing and prevent duplicate side-effects.

* Internal Commands:
Enables deferred or background execution of internal tasks within a module (e.g.,
sending notification emails or expiring waitlist holds) with automated retry and
error handling.

5. TESTING & ARCHITECTURAL GOVERNANCE
--------------------------------------------------------------------------------
The project features a rigorous, multi-tier testing strategy:
* Unit Tests: Pure domain model testing focusing on invariant logic, free from mock
overhead or database dependencies.
* Integration Tests: End-to-end command/query execution tested against a real database
environment to ensure queries, mappings, and Outbox dispatchers execute flawlessly.
* Architecture Tests (NetArchTest): Automated architecture tests that run on build.
They enforce modular encapsulation, preventing developers from accidentally adding
unauthorized dependencies across module layers.

================================================================================
[بخش فارسی - راست به چپ (RTL)]
================================================================================

۱. مقدمه و هدف مخزن (Introduction & Purpose)
--------------------------------------------------------------------------------
ریپوزیتوری «kgrzybek/modular-monolith-with-ddd» اثر کمیل گژبک (Kamil Grzybek)، یکی
از برجسته‌ترین و استانداردترین مراجع معماری نرم‌افزار در جامعه توسعه‌دهندگان دات‌نت (.NET)
و کل اکوسیستم مهندسی نرم‌افزار به شمار می‌رود.

اهداف بنیادین پروژه:
• ارائه الگویی عملی برای پیاده‌سازی یک معماری یکپارچه ماژولار (Modular Monolith)
با کیفیت آماده برای محیط عملیاتی (Production-Ready) به‌جای یک اثبات ایده (PoC) ساده.
• بهره‌مندی از تمام مزایای میکروسرویس‌ها (نظیر مرزبندی شفاف دامین، استقلال پایگاه‌داده،
کاهش وابستگی‌ها و استقلال تیم‌ها) بدون مواجهه با چالش‌ها و هزینه‌های گزاف توزیع‌شدگی
(تأخیر شبکه، پیچیدگی تراکنش‌های توزیع‌شده، ناهماهنگی داده‌ها و زیرساخت پیچیده).
• نمایش پیاده‌سازی حرفه‌ای الگوهای تاکتیکی طراحی دامین‌محور (Domain-Driven Design) و
طراحی با قابلیت تست‌پذیری حداکثری (Testable Design).

۲. شرح دامنه تجاری: پلتفرم مدیریت رویدادها (Meetup Domain)
--------------------------------------------------------------------------------
این پروژه برای نشان دادن الگوها در شرایط دنیای واقعی، دامنه‌ای ملموس و دارای چالش‌های
کسب‌وکاری یعنی «سیستم مدیریت رویداد و همایش» (شبیه به پلتفرم بین‌المللی Meetup) را
پیاده‌سازی کرده است:

قوانین و مفاهیم بیزینس:
• گروه‌های رویداد (Meeting Groups): اعضا می‌توانند پیشنهاد تشکیل گروه جدید ثبت کنند؛
اما این پیشنهاد تا زمان بازبینی و تأیید توسط مدیران ارشد سیستم فعال نمی‌شود.
• اشتراک‌ها (Subscriptions): هر گروه باید دارای برگزارکننده‌ای با اشتراک معتبر باشد.
هر اشتراک فعال حداکثر ۳ گروه همایش را پوشش می‌دهد.
• جلسات و رویدادها (Meetings): فقط سازمان‌دهنده گروه می‌تواند جلسه جدید تعریف کند.
هر جلسه شامل شرکت‌کنندگان قطعی، انصراف‌دهندگان و لیست انتظار (Waitlist) است.
• ظرفیت و سهمیه‌ها: جلسات می‌توانند سقف ظرفیت داشته باشند؛ پس از پر شدن ظرفیت، ثبت‌نام‌ها
به‌طور خودکار به لیست انتظار منتقل می‌شوند.
• نقش‌های جلسه: هر شرکت‌کننده می‌تواند نقش عادی یا میزبان (Host) داشته باشد. وجود حداقل
یک میزبان برای ویرایش جزئیات و مدیریت لیست افراد الزامی است.
• هزینه‌ها و مهمانان: امکان تعیین هزینه ورودی برای جلسات وجود دارد و اعضا می‌توانند
مهمان همراه بیاورند و هزینه آن‌ها را شخصاً متقبل شوند.
• نظرات (Comments): ثبت نظر، پاسخ و لایک‌کردن دیدگاه‌ها با توجه به تنظیمات جلسه مدیریت می‌شود.

۳. ساختار و تفکیک ماژول‌ها بر اساس مدل C4 (Architecture & Modules)
--------------------------------------------------------------------------------
سیستم با پیروی از متدولوژی مستندسازی C4 (سطوح کانتینر، کامپوننت و کد) و با نمودارهای
PlantUML مستندسازی شده و دارای تفکیک لایه‌ای زیر است:

۱. ماژول API (لایه وب و میزبانی):
- یک لایه بسیار نازک بر بستر ASP.NET Core Web API.
- وظایف: دریافت درخواست‌های HTTP، اعتبارسنجی احراز هویت با ماژول دسترسی، ارسال
فرمان‌ها و پرس‌وجوها به ماژول‌های داخلی و بازگرداندن پاسخ.
- فاقد هرگونه لاجیک تجاری و محاسباتی.

۲. ماژول UserAccess:
- مدیریت هویت کاربری، صدور توکن‌های JWT، نقش‌ها (Roles) و مجوزهای ریزدانه (Permissions).

۳. ماژول Registrations:
- مدیریت چرخه ثبت‌نام، تایید ایمیل و ماشین وضعیت اعتبارسنجی ثبت‌نام کاربران.

۴. ماژول Meetings (هسته مرکزی دامین):
- پیاده‌سازی هسته بیزینس: گروه‌ها، جلسات، ظرفیت‌ها، لیست‌های انتظار و کامنت‌ها.

۵. ماژول Administration:
- جریان‌های کاری اختصاصی مدیران پلتفرم جهت بررسی، تأیید یا رد پیشنهادات گروه‌ها.

۶. ماژول Payments:
- جریان‌های مالی: پرداخت حق اشتراک برگزارکنندگان و هزینه‌های ورودی رویدادها.

۴. الگوهای تاکتیکی DDD و معماری داخلی ماژول‌ها (Tactical DDD & Mechanics)
--------------------------------------------------------------------------------
هر ماژول به عنوان یک واحد خودمختار با رعایت مرزهای نفوذناپذیر طراحی شده است:

• کپسوله‌سازی حداکثری (Strict Encapsulation):
تمامی موجودیت‌های دامین، کلاس‌های EF Core، هندلرها و ریپازیتوری‌ها با سطح دسترسی internal
تعریف شده‌اند. دنیای خارج فقط از طریق یک اینترفیس پابلیک بسیار کوچک (مانند IMeetingsModule)
با ماژول ارتباط برقرار می‌کند.

• مدل‌های غنی دامنه و بی‌خبری از ذخیره‌سازی (Persistence Ignorance):
موجودیت‌های دامین کلاس‌های خالص (POCO) هستند و هیچ وابستگی به زیرساخت یا پایگاه‌داده ندارند.
تمام اینوریانت‌ها (Invariants) و قوانین درون ریشه‌های تجمیع (Aggregate Roots) حفظ می‌شوند.

• مقابله با وسواس نوع‌های بدوی (Primitive Obsession):
استفاده گسترده از Value Objectها به‌جای انواع داده‌ای خام نظیر string یا Guid.

• تفکیک دستورات و پرس‌وجوها (CQRS):
- مسیر تغییرات (Write): با بهره‌گیری از MediatR و Entity Framework Core برای تضمین صحت کامل داده‌ها.
- مسیر خواندن (Read): با اجرای مستقیم کوئری‌های خام و با بازدهی بسیار بالای SQL توسط Dapper
مستقیماً روی DTOها، بدون درگیر کردن دامین مدل یا Change Tracker.

• ارتباط ناهمگام میان ماژول‌ها (Asynchronous Communication):
هیچ ماژولی حق فراخوانی مستقیم متدها یا پایگاه‌داده ماژول دیگر را ندارد. کلیه تبادلات منحصراً
از طریق انتشار رویداد روی Event Bus صورت می‌پذیرد.

• تضمین تراکنش‌ها با الگوهای Outbox و Inbox:
- الگوی Outbox: رویدادهای یکپارچه‌سازی در همان تراکنش محلی دیتابیس در جدول Outbox ذخیره
می‌شوند و پردازشگر پس‌زمینه (Quartz.NET) آنها را بدون از دست رفتن اطلاعات منتشر می‌کند.
- الگوی Inbox: دریافت پیام‌ها در جدول Inbox ذخیره می‌شود تا از پردازش تکراری رویدادها
جلوگیری شده و ضمانت پردازش حداقل یک‌باره (At-Least-Once) حاصل شود.

• فرمان‌های داخلی (Internal Commands):
انجام پردازش‌های زمان‌بندی‌شده، ارسال ایمیل‌ها یا کارهای پس‌زمینه درون هر ماژول به شکل مطمئن
با قابلیت تلاش مجدد (Retry) خودکار.

۵. استراتژی تست و نظارت خودکار بر معماری (Testing & Arch Tests)
--------------------------------------------------------------------------------
• تست‌های واحد (Unit Tests): متمرکز بر اعتبارسنجی لاجیک خالص دامین مدل، بدون وابستگی به دیتابیس
یا شبیه‌سازی‌های زائد (Mocking).
• تست‌های یکپارچگی (Integration Tests): تست تراکنش‌های واقعی، دیتابیس و اجرای کامل فرآیندها.
• تست‌های خودکار معماری (NetArchTest): آزمون‌های کدی که نقض قوانین ماژولار، وابستگی‌های غیرمجاز و
نشت کپسوله‌سازی را در زمان Build شناسایی و رد می‌کنند.
================================================================================

Git

2026-08-27T15:12:59Z

Mkaravi: Created page with "== Git Commands == === 1. Setting & Creating Projects === {| class="wikitable" |+ ! Command !! Description |- | <code>git init</code> || Initialize a local Git repository |- | <code>git clone ssh://git@github.com/[username]/[repository-name].git</code> || Create a local copy of a remote repository |} === 2. Basic Snapshotting === {| class="wikitable" |+ ! Command !! Description |- | <code>git status</code> || Check status |- | <code>git add [file-name.txt]</code> || Ad..."

== Git Commands ==

=== 1. Setting & Creating Projects ===
{| class="wikitable"
|+
! Command !! Description
|-
| <code>git init</code> || Initialize a local Git repository
|-
| <code>git clone ssh://git@github.com/[username]/[repository-name].git</code> || Create a local copy of a remote repository
|}

=== 2. Basic Snapshotting ===
{| class="wikitable"
|+
! Command !! Description
|-
| <code>git status</code> || Check status
|-
| <code>git add [file-name.txt]</code> || Add a file to the staging area
|-
| <code>git add -A</code> || Add all new and changed files to the staging area
|-
| <code>git commit -m "[commit message]"</code> || Commit changes
|-
| <code>git rm -r [file-name.txt]</code> || Remove a file (or folder)
|-
| <code>git remote -v</code> || View the remote repository of the currently working file or directory
|}

=== 3. Branching & Merging ===
{| class="wikitable"
|+
! Command !! Description
|-
| <code>git branch</code> || List branches (the asterisk denotes the current branch)
|-
| <code>git branch -a</code> || List all branches (local and remote)
|-
| <code>git branch [branch name]</code> || Create a new branch
|-
| <code>git branch -d [branch name]</code> || Delete a branch
|-
| <code>git push origin --delete [branch name]</code> || Delete a remote branch
|-
| <code>git checkout -b [branch name]</code> || Create a new branch and switch to it
|-
| <code>git checkout -b [branch name] origin/[branch name]</code> || Clone a remote branch and switch to it
|-
| <code>git branch -m [old branch name] [new branch name]</code> || Rename a local branch
|-
| <code>git checkout [branch name]</code> || Switch to a branch
|-
| <code>git checkout -</code> || Switch to the branch last checked out
|-
| <code>git checkout -- [file-name.txt]</code> || Discard changes to a file
|-
| <code>git merge [branch name]</code> || Merge a branch into the active branch
|-
| <code>git merge [source branch] [target branch]</code> || Merge a branch into a target branch
|-
| <code>git stash</code> || Stash changes in a dirty working directory
|-
| <code>git stash clear</code> || Remove all stashed entries
|-
| <code>git stash pop</code> || Apply latest stash to working directory
|}

=== 4. Sharing & Updating Projects ===
{| class="wikitable"
|+
! Command !! Description
|-
| <code>git push origin [branch name]</code> || Push a branch to your remote repository
|-
| <code>git push -u origin [branch name]</code> || Push changes to remote repository (and remember the branch)
|-
| <code>git push</code> || Push changes to remote repository (remembered branch)
|-
| <code>git push origin --delete [branch name]</code> || Delete a remote branch
|-
| <code>git pull</code> || Update local repository to the newest commit
|-
| <code>git pull origin [branch name]</code> || Pull changes from remote repository
|-
| <code>git remote add origin ssh://git@github.com/[username]/[repository-name].git</code> || Add a remote repository
|-
| <code>git remote set-url origin ssh://git@github.com/[username]/[repository-name].git</code> || Set a repository's origin branch to SSH
|}

=== 5. Inspection & Comparison ===
{| class="wikitable"
|+
! Command !! Description
|-
| <code>git log</code> || View changes
|-
| <code>git log --summary</code> || View changes (detailed)
|-
| <code>git log --oneline</code> || View changes (briefly)
|-
| <code>git diff [source branch] [target branch]</code> || Preview changes before merging
|}