قوانین و استانداردهای بکاند
بکاند تریپیلون از ابتدا بهصورت یک Modular Monolith با Go و PostgreSQL ساخته میشود. مرزها Feature-based هستند، قواعد Clean Architecture درون هر ماژول اجرا میشوند و طراحی باید امکان استخراج یک ماژول به سرویس مستقل را بدون ایجاد پیچیدگی زودهنگام حفظ کند.
این مجموعه مرجع الزامآور توسعهدهندگان، Reviewerها و تیم عملیات است. واژه «باید» الزام، «نباید» ممنوعیت و «بهتر است» توصیهای است که انحراف از آن باید در Pull Request توضیح داده شود.
خط مبنا
| موضوع | تصمیم پایه |
|---|---|
| زبان | آخرین Patch پایدار Go 1.26؛ در تاریخ 2026-09-09 نسخه 1.26.8؛ حداقل نسخه Build و CI نیز 1.26.8 است |
| پایگاه داده | PostgreSQL 18 روی آخرین Minor پشتیبانیشده؛ در تاریخ 2026-08-02 نسخه 18.4 |
| معماری | Modular Monolith، Clean Architecture و بستهبندی Feature-based |
| HTTP | فقط Standard Library یعنی net/http و http.ServeMux، قرارداد REST و OpenAPI 3.1 |
| دسترسی داده | pgx/v5 و SQL، پارامتر، Row و Scan دستی و صریح؛ بدون Code Generator و ORM عمومی |
| Migration | فایل SQL با tern/v2 و راهبرد Expand/Contract |
| Tenant | هر Building یک Tenant؛ Account سراسری و Membership وابسته به Building |
| پردازش غیرهمزمان | صف پایدار PostgreSQL و Transactional Outbox |
| فایل | ArvanCloud Object Storage در Production و MinIO در Development، پشت پورت S3-compatible |
| استقرار فعلی | Docker روی VPS ایران؛ CI/CD خودکار فقط برای محیط Development |
نسخههای Patch و Minor باید با Renovate یا Dependabot پیشنهاد شوند و پس از عبور از آزمونها ارتقا یابند. ارتقای Major یا تغییر یکی از تصمیمهای این جدول بدون ADR مجاز نیست.
دامنه محصول
مرزهای فنی باید از معماری محصول و دامنه محصول پیروی کنند. فهرست اولیه Featureها چنین است:
- هویت و دسترسی، ساختمان، واحد، عضویت، نقش و مجوز
- حسابداری، شارژ و صورتحساب، پرداخت، تسویه و گزارش مالی
- درخواست تعمیرات، ارجاع کار و Ticket با پاسخ، یادداشت داخلی، SLA و تاریخچه تصمیم
- مرکز پیام، اعلان، رزرو امکانات، مهمان، تردد، Front Desk و مرسولات
- نیروی انسانی و شیفت، اسناد و قوانین، رایگیری، شکایت و تخلف
- املاک، مدیریت پلتفرم، یکپارچهسازی، AI و اتوماسیون
در نسخه اول Chat کاربر به کاربر وجود ندارد. REST منبع حقیقت است، SSE برای بهروزرسانی Foreground وب و Push برای موبایل استفاده میشود.
وضعیت تصمیمها
| تصمیم | وضعیت |
|---|---|
| Go، PostgreSQL و Modular Monolith | تصویبشده |
| مدل Tenant بر پایه Building | تصویبشده |
| ورود با موبایل ایران و OTP ملیپیامک | تصویبشده |
| Refresh Token چرخشی و چنددستگاهی | تصویبشده |
| ArvanCloud در Production و MinIO در Development | تصویبشده |
| درگاه پرداخت | باز؛ باید پشت Adapter مستقل بماند |
| یک VPS یا تفکیک App و Database | باز؛ کد نباید به توپولوژی وابسته شود |
| ارائه Video | خارج از نسخه اول |
حاکمیت سند
- مالک محتوا Tech Lead است و بازبینی حساس امنیتی با Reviewer امنیت انجام میشود.
- این مجموعه حداقل هر سه ماه و پس از هر تغییر Major فناوری بازبینی میشود.
- نخستین بازبینی دورهای باید تا 2026-11-02 انجام شود.
- هر استثنا باید زمان انقضا، مالک، ریسک و ADR مرتبط داشته باشد.
- مستند API هر Feature باید همزمان با قرارداد OpenAPI و پیش از Merge بهروزرسانی شود.