‫Domain-Driven Design (DDD)؛ بخش چهارم: Bounded Contexts

• بخشی که با مدیریت کتاب‌ها سر و کار دارد: ثبت، ویرایش، دسته‌بندی.
• بخشی که به امانت و بازگشت کتاب‌ها اختصاص دارد: چه کسی چه کتابی را گرفت؟ تا کی باید برگرداند؟ آیا دیرکرد دارد؟
• بخشی که اعضا و کاربران را مدیریت می‌کند: ثبت‌نام، تمدید عضویت، وضعیت فعال یا غیرفعال بودن.
• شاید هم بخش‌های جنبی مثل پرداخت جریمه‌ها یا حتی گزارش‌گیری و آمارگیری.

• Catalog Sub-Domain: برای مدیریت کتاب‌ها و منابع.
• Circulation Sub-Domain: برای امانت و بازگشت.
• Membership Sub-Domain: برای مدیریت اعضا.
• Billing/Payment Sub-Domain: برای جریمه‌ها یا تراکنش‌های مالی.

• مثلاً در Catalog Context، مهم‌ترین موجودیت‌ها (Entities) چیزهایی مثل Book، Author، Category هستند. قوانین اینجا حول اطلاعات کتاب می‌چرخد.
• اما در Circulation Context، دیگر کتاب فقط یک «منبع قابل امانت» است. موجودیت اصلی می‌شود Loan یا BorrowingRecord. قوانین اینجا با تاریخ امانت، تمدید و دیرکرد سروکار دارند.
• در Membership Context، ما با Member، MembershipType یا Subscription سر و کار داریم، و زبان این فضا با Catalog کاملاً فرق دارد.
• اگر هم Billing Context داشته باشیم، قوانینش روی Fine و PaymentTransaction متمرکز می‌شوند.

• بین Catalog و Circulation یک ارتباط واضح داریم:
• Circulation باید بداند کدام کتاب در کاتالوگ ثبت شده است. پس Catalog به نوعی Upstream Context می‌شود و Circulation نقش Downstream.
• بین Membership و Circulation هم رابطه‌ای مشابه داریم:
• Circulation نمی‌تواند به هر کسی کتاب امانت دهد؛ باید وضعیت عضویت را از Membership بپرسد. پس باز Membership یک Upstream برای Circulation است.
• Billing هم به Circulation وابسته است: چون جریمه‌ها بر اساس دیرکرد امانت‌ها تعریف می‌شوند. اینجا Circulation اطلاعات لازم را به Billing می‌دهد.

Catalog ----> Circulation <---- Membership
                    |
                    v
                 Billing

• CatalogDbContext فقط موجودیت‌های کتاب‌ها و دسته‌بندی‌ها را نگه می‌دارد.
• CirculationDbContext روی رکوردهای امانت متمرکز است.
• MembershipDbContext فقط با اعضا و وضعیت آن‌ها سروکار دارد.
• BillingDbContext هم کار خودش را می‌کند.

• Book: کتاب با ویژگی‌هایی مثل عنوان، سال انتشار، ISBN.
• Author: نویسنده با نام و مشخصات پایه.
• Category: دسته‌بندی موضوعی کتاب‌ها.

• ISBN: یک شناسهٔ منحصربه‌فرد که خودش قواعد اعتبارسنجی دارد (مثلاً طول و الگوی معتبر).
• PublicationInfo: شامل ناشر و سال انتشار.

• Book به‌عنوان ریشهٔ اصلی؛ چرا که Author یا Category می‌توانند مستقل مدیریت شوند، اما در تعامل با امانت‌ها، معمولاً کتاب واحد پایه است.

• Loan (یا BorrowingRecord): رکوردی که می‌گوید کدام عضو چه کتابی را کی گرفته.
• Reservation: درخواست رزرو یک کتاب.

• LoanPeriod: شامل تاریخ شروع و پایان.
• DueDate: تاریخ بازگشت مورد انتظار.

• Loan چون تمام قوانین (مثل تمدید یا دیرکرد) حول آن می‌چرخد.
• همچنین می‌توان Reservation را یک Aggregate جدا در نظر گرفت، چون چرخهٔ زندگی خودش را دارد.

• Member: شخصی که عضو کتابخانه است.
• MembershipType: نوع عضویت (مثلاً سالانه، دانشجویی، ویژه).

• ContactInfo: شامل ایمیل، شماره تماس.
• Address: آدرس پستی یا محل سکونت.

• Member چون همه‌چیز (نوع عضویت، وضعیت فعال یا غیرفعال بودن) به او متصل است.

• Fine: جریمهٔ ایجاد شده برای دیرکرد یا خسارت.
• PaymentTransaction: ثبت پرداخت‌ها.

• Money: شامل مقدار و واحد پول.
• PaymentMethod: نوع پرداخت (کارت، نقدی، آنلاین).

• Fine (به‌عنوان منبع بدهی).
• PaymentTransaction می‌تواند یک Aggregate مستقل باشد، چون چرخهٔ زندگی‌اش جدا از جریمه تعریف می‌شود.

public class CirculationDbContext : DbContext
{
    public DbSet<Loan> Loans { get; set; }
    public DbSet<Reservation> Reservations { get; set; }
}

// نقشهٔ سادهٔ روابط (Context Map)

     +--------------------+
     |   Membership BC    |
     |--------------------|
     | Member             |
     | MembershipType     |
     +--------------------+
              ^
              |  Validate member
              |
   +----------+-----------+
   |                      |
   |                      |
   v                      v
+------------------+   +---------------------+
| Circulation BC   |   | Reservation BC      |
|------------------|   |---------------------|
| Loan             |   | ReservationQueue    |
| LoanPolicy       |   | PickupWindow        |
+------------------+   +---------------------+
      |   ^                         ^
      |   |                         |
      |   |LoanReturned             | consumes LoanReturned
      |   +-------------------------+
      |   checks ActiveReservation
      v
+------------------+
|   Billing BC     |
|------------------|
| Fine             |
| Payment          |
+------------------+

• صدور قبض شارژ (IssueChargeBill) – جایی که بدهی واحدها محاسبه و به قبض تبدیل می‌شود.
• مشاهده قبض (ViewChargeBill) – امکان مشاهده و دسترسی به اطلاعات قبض.
• پرداخت قبض (PayChargeBill) – مرحله‌ای که واحدها مبلغ را تسویه می‌کنند.
• محاسبه جریمه تأخیر (CalculateLatePenalty) – بخشی که در صورت دیرکرد، مبلغ اضافه‌ای را لحاظ می‌کند.

• Billing Sub-Domain → مسئول صدور و مدیریت قبض‌ها.
• Payment Sub-Domain → مسئول پرداخت‌ها و تسویه‌ها.
• Penalty Sub-Domain → مسئول منطق جریمهٔ تأخیر.
• Query/Read Sub-Domain → بیشتر به نمایش اطلاعات قبض‌ها می‌پردازد (در اصل یک Supporting Sub-Domain است).

• مسئول: صدور قبض شارژ، نگهداری وضعیت قبض‌ها.
• خروجی: قبض‌هایی با وضعیت اولیه (Unpaid).

• مسئول: ثبت پرداخت‌ها، تغییر وضعیت قبض به Paid.
• تعامل: قبض را از Billing می‌گیرد و پس از پرداخت، وضعیتش را به‌روز می‌کند.

• مسئول: محاسبه جریمهٔ دیرکرد بر اساس تاریخ سررسید.
• تعامل: به داده‌های Billing نیاز دارد (تاریخ صدور و سررسید قبض‌ها).

• مسئول: نمایش و جست‌وجوی قبض‌ها برای کاربران.
• تعامل: از Billing داده می‌خواند، اما تغییر مستقیم نمی‌دهد.

• Billing → Payment : Billing قبض را صادر می‌کند، Payment آن را تسویه می‌کند. (Relationship: Customer-Supplier، Payment مشتریِ Billing است.)
• Billing → Penalty : Penalty برای محاسبه جریمه به اطلاعات Billing وابسته است. (Relationship: Conformist، Penalty باید مدل Billing را بپذیرد.)
• Billing → ChargeQuery : ChargeQuery داده‌ها را از Billing می‌خواند. (Relationship: Open Host Service یا Published Language، چون Billing داده‌ها را در قالبی قابل مصرف منتشر می‌کند.)

// Context map

   +-------------------+             +-------------------+
   |   Billing Context |<----------->| Payment Context   |
   |  (Issue Charge)   |   Supplier  |  (Pay Charge)     |
   +-------------------+             +-------------------+
             |
             | Conformist
             v
   +-------------------+
   | Penalty Context   |
   | (Late Penalty)    |
   +-------------------+
             ^
             | OHS / PL
             |
   +-------------------+
   | ChargeQuery Ctx   |
   | (View Charges)    |
   +-------------------+

• ChargeBill (قبض شارژ)
• موجودیت مرکزی که همه چیز حول آن می‌چرخد.

• Unit (واحد آپارتمانی) → برای هر قبض باید مشخص باشد که مربوط به کدام واحد است.
• ChargeItem (آیتم‌های شارژ) → مثلاً هزینه نظافت، نگهبانی، آسانسور.

• Money (مبلغ با واحد پولی)
• DueDate (تاریخ سررسید)

• Payment (پرداخت)

• Transaction (جزئیات هر تراکنش) → شماره پیگیری، زمان پرداخت.
• Payer (پرداخت‌کننده، که همان ساکن یا مالک است).

• PaymentMethod (روش پرداخت: کارت، درگاه، نقدی)
• Money (مبلغ پرداختی، دوباره از همان Value Object استفاده می‌کنیم تا سازگار باشد)

• PenaltyPolicy (سیاست محاسبه جریمه)

• LatePenalty (جریمهٔ محاسبه‌شده برای یک قبض خاص)

• Rate (نرخ جریمه: مثلاً ۲٪ ماهانه)
• Duration (مدت تأخیر بر اساس تاریخ سررسید)

• ChargeBillView (نمای خلاصه قبض)
• PaymentStatusView (وضعیت پرداخت قبض)

• Period (بازه زمانی جستجو، مثل فروردین ۱۴۰۴)

• ChargeBill در Billing خلق می‌شود.
• Payment در Payment وضعیت آن را تغییر می‌دهد.
• PenaltyPolicy از Billing سررسیدها را می‌گیرد و LatePenalty تولید می‌کند.
• ChargeBillView در ChargeQuery تنها مصرف‌کنندهٔ داده است و هیچ منطق تجاری اضافه نمی‌کند.

• Scheduling (زمان‌بندی و رزرو): قلب ماجرا همین‌جاست؛ جایی که وقت‌های خالی پزشکان مدیریت می‌شود و بیماران رزرو می‌کنند.
• Billing & Payment (صورتحساب و پرداخت): بعد از رزرو، بحث پول وسط می‌آید. این زیردامنه فقط به جریان مالی سروکار دارد.
• User Management (مدیریت کاربران): اطلاعات پایهٔ بیماران و پزشکان، بدون اینکه خیلی وارد جزئیات بالینی شویم.

• مسئول مدیریت نوبت‌ها (Appointment)
• قوانین: جلوگیری از تداخل زمان‌ها، امکان لغو یا تغییر وضعیت وقت.

• مدیریت پرداخت‌ها (Payment)
• قوانین: موفق بودن یا شکست خوردن تراکنش، صدور رسید.

• مدیریت اطلاعات پایهٔ پزشک و بیمار
• قوانین: ثبت مشخصات فردی، نگهداری داده‌های هویتی، بدون ورود به فرآیندهای پزشکی.

• Scheduling → User Management
• برای رزرو یک وقت، باید هویت پزشک و بیمار را بشناسیم. پس Scheduling وابسته به اطلاعات پایه‌ای User Management است. (Dependency)
• Scheduling → Billing & Payment
• وقتی وقت رزرو شد، جریان کار به Payment سپرده می‌شود. اما این وابستگی یک‌طرفه است: Payment فقط به سرنوشت خودش اهمیت می‌دهد و از جزئیات نوبت خبر ندارد. (Customer-Supplier)

• Properties: تاریخ/ساعت، وضعیت (Reserved, Cancelled, Completed)
• References: بیمار، پزشک (به صورت Value Object یا Reference ID، نه Entity کامل)

• (اینجا Appointment کافی است؛ پزشک و بیمار در این Context فقط نقش reference دارند.)

• TimeSlot (نمایش بازه زمانی)
• AppointmentStatus

• Properties: مبلغ، روش پرداخت (کارت، نقدی)، وضعیت پرداخت (Pending, Success, Failed)
• References: شناسهٔ وقت (AppointmentId)

• Money (شامل Amount و Currency)
• PaymentMethod

• Patient
• Doctor

• Patient: شامل اطلاعات هویتی، شماره تماس
• Doctor: شامل تخصص، اطلاعات تماس

• Name, ContactInfo, Specialty

//Context map

   [User Management BC]
         ↑
         │  (اطلاعات پایه بیمار/پزشک)
         │
   [Scheduling BC]  ───────►  [Billing & Payment BC]
         │                   (پرداخت بابت وقت رزرو شده)
         │
         (قلب سیستم: وقت ویزیت)