● 1.0.0-beta.1 · پایتون ۳٫۱۲ · FastAPI · MIT
دفتر حساب را
همانجا نگه دار که کسبوکار حرف میزند.¶
بنویس فروش ۲۵۰ک و ثبت میشود. یک حساب واحد در تلگرام، بله و روبیکا،
و یک API روی همان قواعد. پول دقیق است، تقویم جلالی است، و پشت هر تراکنش یک سند
دوطرفهٔ تراز نشسته است.
نصب¶
curl -fsSL https://raw.githubusercontent.com/Emadhabibnia1385/KasbBook/main/scripts/install.sh | sudo bash
دبیان یا اوبونتو، پایتون ۳٫۱۱ به بالا، و داکر برای پایگاه داده. فقط یک چیز میپرسد — توکن ربات — و بقیه را خودش میسازد، چون کلید امضایی که کسی تایپش کند کلیدی است که کسی میتواند حدسش بزند. دو بار اجرا کردنش هم بیخطر است.
این نسخه بتاست
برای نویسندهاش در تولید اجرا میشود و تستهایش کاملاند، ولی هنوز دست آدمهای
زیاد و دفترهای زیاد نبوده. پشتیبان بگیر — scripts/backup.sh این کار را
برایت میکند و چیزی را که نوشته راستیآزمایی میکند — و
نقشهٔ راه را بخوان تا بدانی چه چیزی عمداً ساخته نشده.
چه کار میکند¶
-
دفتر، با دفتر کل واقعی
دفترهای شخصی، کسبوکار، تیمی و سازمانی زیر یک حساب. هر تراکنش یک سند تراز مینویسد، پس دفترها را میشود اثبات کرد، نه فقط خواند. دفتر دوطرفه.
-
پولی که دقیق میماند
همهجا
Decimal، در پستگرسNUMERIC(28,4)، و روی HTTP یک رشته — چون JSON فقط یک نوع عددی دارد و آن float است، و12500000.15از آن رفتوبرگشت سالم بیرون نمیآید. -
جلالی، آنطور که باید
دورهای مثل
۱۴۰۳-۰۵پیش از هر کوئری به بازهٔ میلادی تبدیل میشود. دیتابیس هرگز مقدار جلالی نمیبیند و خواننده هرگز میلادی. -
یک حساب، چند پیامرسان
آیدی پیامرسان هرگز خودِ حساب نیست — به آن اشاره میکند. تلگرامت را از دست بده، دفترهایت میمانند. مدل داده.
-
حقوق برای تیم
دوره، سهم اعضا، کارکرد ثبتشده، کسر و اضافه، فیشهایی که هر ورودی را منجمد میکنند، پرداخت مرحلهای، و خزانهای که پیش از تقسیم سود برداشته میشود. حقوق و خزانه.
-
APIای روی همان قواعد
نه یک پیادهسازی دوم. ربات و API هر دو همان سرویسها را صدا میزنند، پس نمیشود قاعدهای را در یکی رعایت کرد و در دیگری فراموش. رابط برنامهنویسی.
چطور سرِ هم شده¶
تلگرام بله روبیکا
│ │ │
▼ ▼ ▼
┌─────────────────────────────────────────┐
│ adapters/ ترجمهٔ پیام │ نه دیتابیس، نه قاعده
└───────────────────┬─────────────────────┘
▼
┌─────────────────────────────────────────┐
│ bot/ صفحهها و مسیریابی │ بدون نام پیامرسان
└───────────────────┬─────────────────────┘
│
┌───────────────────┼─────────────────────┐
│ api/ ───────────┤ │ خواندن، صدا زدن، ترجمهٔ خطا
└───────────────────┼─────────────────────┘
▼
┌─────────────────────────────────────────┐
│ modules/*/service.py │ هر قاعده، دقیقاً یک بار
└───────────────────┬─────────────────────┘
▼
PostgreSQL · Redis · Alembic
دو مشتری، یک مجموعه قاعده. چرا درزها اینجا هستند.
اگر چیزی درست به نظر نمیرسد¶
عیبیابی اولین صفحهای است که باید بخوانی. هر مدخل آن خرابیای است که واقعاً در این پروژه رخ داده، به شکل نشانه ← علت ← رفع — چون تقریباً در همهشان، نشانه جای دیگری را نشان میداد.
بعد کجا برویم¶
| نصبش کن و چیزی ثبت کن | شروع |
| شکلش را بفهم | معماری |
| از اسکریپت صدایش بزن | رابط برنامهنویسی |
| برای دیگران اجرایش کن | عملیات · امنیت |
| تغییرش بده | توسعه |