معماری سیستم

• ۰۱

  قرار است چیز بزرگی بسازید و می‌خواهید از همان بار اول درست باشد.

• ۰۲

  سیستم فعلی به‌سختی تغییر می‌کند و کسی نمی‌داند چرا.

• ۰۳

  دو تیم مدام کار همدیگر را خراب می‌کنند.

• ۰۴

  رشد در راه است و نمی‌دانید اول کجای سیستم کم می‌آورد.

1. D/۰۱

   مدل دامنه و داده

   کسب‌وکار را در قالب موجودیت‌ها، روابطشان و قواعدی که همیشه باید برقرار بمانند ترسیم می‌کنیم. بعدها تغییر دادن هیچ بخشی از سیستم به سختی این بخش نیست، پس اول روی کاغذ درستش می‌کنیم؛ و همین مدل مرجعی می‌ماند که هر صفحه و هر API بر پایه‌اش ساخته می‌شود.

   شامل

   • مدل موجودیت–رابطه، با همه‌ی فیلدها و معنای هر کدام
   • قواعدی که همیشه باید برقرار باشند، به زبان ساده
   • چرخه‌ی عمر رکوردهای اصلی: وضعیت‌ها و این‌که چه کسی می‌تواند تغییرشان دهد
   • نکات نگهداری و حریم خصوصی برای هر جدول

2. D/۰۲

   مرز سرویس‌ها

   تصمیم می‌گیریم سیستم از چه اجزایی ساخته شود، هر جزء مسئول چه چیزی باشد و اجزا چطور با هم حرف بزنند: فراخوانی API جایی که همین حالا پاسخ لازم است، رویداد جایی که می‌تواند صبر کند. با مرزهای روشن، تیم‌ها می‌توانند موازی کار کنند بی‌آن‌که کار همدیگر را خراب کنند.

   شامل

   • نقشه‌ی زمینه: همه‌ی سرویس‌ها و داده‌ای که هر کدام مسئول آن است
   • قرارداد API میان سرویس‌ها، با OpenAPI یا gRPC
   • رویدادها و صف‌ها، با این‌که چه کسی منتشر می‌کند و چه کسی گوش می‌دهد
   • آنچه هرگز نباید مستقیم به اشتراک گذاشته شود، و چرا

3. D/۰۳

   سندهای تصمیم

   هر انتخاب مهم را در قالب یک سند تصمیم معماری می‌نویسیم: مسئله، گزینه‌هایی که بررسی کردیم، هزینه‌ی هر کدام و این‌که چرا همین را برگزیدیم. اگر سه سال بعد کسی بپرسد «چرا این‌طوری است؟»، جوابش در مخزن کد است.

   شامل

   • یک سند برای هر تصمیم، شماره‌دار و تاریخ‌دار
   • گزینه‌ها با بده‌بستان‌های صادقانه، نه فقط گزینه‌ی برنده
   • پیامدها: چه چیزی را آسان و چه چیزی را سخت می‌کند
   • وضعیت هر سند، که با بازنگری تصمیم به‌روز می‌شود

   ADR-0007 · نگهداری رزروها در PostgreSQL

   پذیرفته‌شده · ۲۲ اسفند

   زمینه

   • رزروها به سازگاری کامل نیاز دارند: هیچ نوبتی نباید دو بار فروخته شود.
   • بار پیش‌بینی‌شده: ۴۰ عملیات نوشتن در ثانیه در ساعت اوج.

   گزینه‌ها

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

   تصمیم

   • PostgreSQL، با ایندکس یکتا روی (clinic_id, slot_at).

   پیامدها

   • + فقط یک پایگاه داده که باید از آن پشتیبان گرفت و رفتارش را فهمید.
   • − گزارش‌ها از رپلیکا خوانده می‌شوند که چند ثانیه عقب است.

4. D/۰۴

   نمودارهایی که کهنه نمی‌شوند

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

   شامل

   • نماهای زمینه، کانتینر و کامپوننت به سبک C4
   • نمودار به شکل کد، نسخه‌بندی‌شده همراه مخزن
   • نمودار توالی برای جریان‌های مهم
   • یک خلاصه‌ی یک‌صفحه‌ای برای هر تازه‌واردی به سیستم

   • docs/
   • overview.mdاز اینجا شروع کنید
   • architecture/
   • context.mmdC4 · زمینه
   • containers.mmdC4 · کانتینرها
   • booking-flow.mmdتوالی
   • adr/
   • 0001-record-decisions.mdپذیرفته‌شده
   • 0007-bookings-in-postgres.mdپذیرفته‌شده
   • data-model.dbmlمدل داده
   • runbook.mdعملیات

5. D/۰۵

   بررسی ریسک و مقیاس

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

   شامل

   • حالت‌های شکست و این‌که هر کدام تا کجا اثر می‌گذارد
   • برآورد بار و این‌که اولین گلوگاه کجا خواهد بود
   • بررسی امنیتی جریان داده و دسترسی‌ها
   • فهرست شاخص‌هایی که زودتر از همه هشدار می‌دهند

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

6. D/۰۶

   نقشه‌ی راه عملی

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

   شامل

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

   1. هفته‌ی ۱ تا ۳

      هسته‌ی رزرو

      → رزرو، لغو و جابه‌جایی نوبت

   2. هفته‌ی ۴ تا ۶

      پرداخت

      → پرداخت آنلاین و بازگشت وجه

   3. هفته‌ی ۷ و ۸

      اعلان‌ها

      → یادآوری با پیامک و ایمیل

   4. هفته‌ی ۹ تا ۱۱

      داشبورد کلینیک

      → برنامه‌ها و گزارش‌ها

1. ۰۱

   شنیدن

   کاربران، محدودیت‌ها، بودجه و سیستم قدیمی‌ای که کسی جرئت دست زدن به آن را ندارد. آن‌قدر می‌پرسیم تا مسئله روشن شود.

2. ۰۲

   مدل‌سازی

   اول دامنه و داده را مدل می‌کنیم؛ بیشتر خطاهای معماری از همین‌جا شروع می‌شوند.

3. ۰۳

   تصمیم

   گزینه‌ها با بده‌بستان‌های صادقانه، در قالب سندهای تصمیمی که می‌توانید زیر سؤال ببرید.

4. ۰۴

   تحویل

   مستندات، نمودارها و نقشه‌ی راهی که تیم شما — یا ما — بتواند بر اساسش بسازد.

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

1. هفته‌ی ۱

   جلسه‌های کاری با تیم شما: کاربران، هدف‌ها، محدودیت‌ها و سیستم‌های فعلی.

2. هفته‌ی ۲

   پیش‌نویس مدل دامنه و داده، بازبینی‌شده با کسانی که کسب‌وکار را بهتر از همه می‌شناسند.

3. هفته‌ی ۳ و ۴

   مرز سرویس‌ها، یکپارچه‌سازی‌ها و تصمیم‌های کلیدی، هر کدام مکتوب در یک سند تصمیم.

4. هفته‌ی ۵

   بررسی ریسک و مقیاس، و بعد نقشه‌ی راه که به چند مرحله تقسیم می‌شود.

5. هفته‌ی ۶

   تحویل: همه‌چیز را با تیمتان مرور می‌کنیم و به سؤال‌های سخت جواب می‌دهیم.

• سند معماری

  یک سند واحد که سیستم را توضیح می‌دهد: اجزا، داده‌ها و منطق پشت هر کدام.

• سندهای تصمیم

  هر انتخاب و بده‌بستان‌هایش، در مخزن کد شما و به زبان ساده.

• نمودار به شکل کد

  نمودارهایی که تیمتان کنار کد ویرایش می‌کند، پس هیچ‌وقت کهنه نمی‌شوند.

• مدل داده

  مدل کامل، با معنای هر فیلد، قواعد و چرخه‌ی عمرش.

• نقشه‌ی راه

  مرحله‌ها و برآوردهایی که تیم شما، یا هر تیمی، می‌تواند بر اساسش بسازد.

• یک بازبینی پس از شروع ساخت

  بررسی این‌که طراحی در عمل چطور جواب می‌دهد و چه چیزی باید تنظیم شود.

• C4 model
• ADRs
• Event storming
• PostgreSQL
• OpenAPI
• gRPC
• NATS / Kafka
• Threat modelling

• API و بک‌اند

  بخشی که کسی نمی‌بیند، ساخته‌شده تا هرگز به چشم نیاید.

  بیشتر بخوانید →

• زیرساخت و DevOps

  سرپا می‌ماند، حتی وقتی چیزی از کار می‌افتد.

  بیشتر بخوانید →

• مهندسی معکوس

  وقتی مستندات همراه فروشنده رفت.

  بیشتر بخوانید →