Full-Stack · تقنيات العقارات2026 · قيد التنفيذ

منصة Homie

نظام موحَّد لإدارة العقارات، يتعامل مع العقارات والمستأجرين وعقود الإيجار والفواتير وكل ما بينها.

HOMIE

Property Management Platform

وحدة مصمَّمة: 12
مسار المصادقة: يعمل
جداول قيد التشغيل: 4

العميل: Homie
القطاع: إدارة العقارات
طبيعة التعاون: بناء منتج Full-Stack
الحالة: قيد التنفيذ
الجدول الزمني: 2026 · تطوير نشط
النطاق: تطبيق ويب وREST API وقاعدة بيانات

01 نظرة عامة

من هو العميل؟

منصة Homie نظام لإدارة العقارات مبني كمستودع واحد (monorepo) متكامل (full-stack). تغطي اثني عشر مجالًا تشغيليًا، هي: طلبات الإيجار والعقارات والمستأجرون والملاك والعقود والفواتير والمدفوعات والمعاينات والمراسلات الداخلية وعناصر التحكم الإدارية.

02 بيان المشكلة

ما المشكلة التي واجهوها؟

احتاج العميل إلى منصة واحدة متكاملة تدير نطاق عملياته العقارية كاملًا: اثنا عشر مجالًا وظيفيًا متمايزًا، بلا طبقة بيانات مشتركة ولا واجهة موحَّدة ولا ضوابط وصول بين الأدوار.

عمليات مجزّأة
اثنا عشر مجالًا تشغيليًا، هي الطلبات والعقارات والمستأجرون والملاك والعقود والفواتير والمدفوعات والمعاينات والرسائل والإدارة، يعمل كل منها بمعزل عن الباقي من دون طبقة بيانات مشتركة تربطها.
غياب المساءلة والتدقيق
لا يوجد سجل معتمد للتغييرات. وقد حُدِّد منذ اليوم الأول أن الحاجة الأساسية هي سجل تدقيق متوافق مع متطلبات الأمان وغير قابل للتغيير، يرصد كل عملية إنشاء وتعديل وحذف مع المُنفِّذ والتاريخ والوقت.
غياب التحكم في الوصول
يعمل الفريق عبر أدوار متعددة بمستويات صلاحيات مختلفة. ومن دون التحكم في الوصول استنادًا إلى الدور، كان بوسع أي موظف الوصول إلى النظام كله دون قيود.
لا مسار لطلبات الإيجار
لم يكن لإدارة طلبات الإيجار نظام مخصص. وقد حُدِّدت بوصفها مجالًا تشغيليًا أساسيًا يتطلب وحدة خاصة بها في المنصة.
لا أساس بيانات علائقي
العقارات والمستأجرون والملاك والفواتير والعقود كيانات مترابطة ببعضها من دون مخطط قاعدة بيانات مشترك. والجداول المقابلة غير موجودة بعد في PostgreSQL، ولم تُولَّد لها هياكل Go (structs).

03 الحل

كيف حللناها؟

صمّمنا وبنينا نظامًا متكاملًا (full-stack) لإدارة العقارات على بنية مستودع واحد (monorepo). تنقسم البنية إلى واجهة خلفية Go REST API وواجهة أمامية Next.js 16، تتشاركان قاعدة بيانات PostgreSQL عبر sqlc، الذي يتيح توليد شيفرة SQL آمنة عند التصريف.

تغطي الواجهة الأمامية 12 وحدة تشغيلية، كلها مصمَّمة بالكامل ومُهيَّأة بهيكلها الأساسي ضمن بنية App Router. والمصادقة تعمل من طرف إلى طرف، أما مخططات قاعدة البيانات التشغيلية ومعالجات API فقيد التطوير النشط.

FE Next.js 16 واجهة React الأمامية React 19TypeScriptTailwind v4
API Go REST API الواجهة الخلفية sqlcمصادقة بملفات تعريف الارتباط
DB PostgreSQL قاعدة البيانات الترحيلاتأنواع sqlc

مستودع واحد · نشر واحد · مثيل PostgreSQL مشترك

Next.js 16
React 19
TypeScript
Go (Golang)
PostgreSQL
sqlc
Tailwind CSS v4
Radix UI
TanStack Query v5
FullCalendar
Tiptap
dnd-kit

شاشات مصمَّمة: مبنية بهيكلها الأساسي، وطبقة البيانات قيد التنفيذ

04 الجدول الزمني للمشروع

أبرز المعالم والمدة

المرحلة 1 الربع الرابع 2025
الاكتشاف والبنية المعمارية
اخترنا التقنيات: Next.js 16 وReact 19 وTypeScript وGo وPostgreSQL وsqlc، وحدّدنا بنية المستودع الواحد (monorepo)، ثم حصرنا نطاق الوحدات الـ12 انطلاقًا من خريطة الموقع في الواجهة الأمامية.
المرحلة 2 الربع الرابع 2025
الهيكل الأولي للواجهة الأمامية ونظام التصميم
بنية Next.js App Router كاملة مبنية بهيكلها الأساسي تحت src/app: مجموعة المصادقة، ومجموعة لوحة المعلومات المحمية، ومقاطع المسارات للوحدات الـ12 كلها. وجميع مكوّنات العرض مصمَّمة بالكامل.
المرحلة 3 الربع الأول 2026
نظام المصادقة والمخطط الأساسي لقاعدة البيانات
إدارة جلسات قائمة على ملفات تعريف الارتباط (HttpOnly وSameSite=Lax) عبر Go API. ثلاث نقاط نهاية فعّالة: POST /api/auth/login وPOST /api/auth/logout وGET /api/auth/me. يضيف أول ترحيل أربعة مخططات أساسية: staff وaudit_log وfeed_items وsettings.
المرحلة 4 الربع الثاني 2026 — قيد التنفيذ
مخططات قاعدة البيانات التشغيلية
كتابة مخططات PostgreSQL للعقارات والمستأجرين والملاك والفواتير والعقود وترحيلها، ثم توليد هياكل Go عبر sqlc.
المرحلة 5 الربع الثاني إلى الثالث 2026
معالجات API لعمليات CRUD والتحكم في الوصول (RBAC)
كتابة معالجات موجّه Go لكل كيانات الأعمال، وتفعيل وسيط RequireRole (المعطَّل حاليًا بتحويله إلى تعليق) لفرض التحكم في الوصول استنادًا إلى الدور على كل المسارات.
المرحلة 6 الربع الثالث 2026
ربط بيانات الواجهة الأمامية
استبدال البيانات التجريبية الثابتة في واجهات الوحدات الـ12 كلها باستدعاءات API حية عبر TanStack Query.

05 التحديات وحلولها

ما العقبات التي واجهتنا وكيف تجاوزناها؟

إعدادات مرنة على عدة مستويات
المشكلةيجب أن يدعم النظام الإعدادات على ثلاثة مستويات في آن واحد: إعدادات المنصة العامة، وتجاوزات خاصة بكل عقار، وتجاوزات خاصة بكل مستأجر، دون جداول منفصلة لكل مستوى.
الحليعتمد مخطط settings على تصميم قائم على JSONB يتيح لجدول واحد حفظ الإعدادات العامة والخاصة بالعقار والخاصة بالمستأجر. ولا حاجة إلى تغيير المخطط عند إضافة مفاتيح إعداد جديدة.
تكامل React 19 مع TanStack Query v5
المشكلةتقوم الواجهة الأمامية على React 19 وTanStack Query v5، وهما مكتبتان جاهزتان للإنتاج، وتتطلبان تكاملًا مقصودًا مع Go API لتخزين حالة الخادم مؤقتًا ومزامنتها.
الحليتولى TanStack Query v5 إدارة حالة الخادم غير المتزامنة كلها بين واجهة Next.js الأمامية وGo API، مع إدارة التخزين المؤقت والمزامنة في طبقة الاستعلامات.
مشاركة الجلسات بين Go وNext.js
المشكلةيتطلب تنسيق الجلسات القائمة على ملفات تعريف الارتباط بين خادم Go وواجهة Next.js الأمامية ضبطًا دقيقًا لإعدادات SameSite والنطاق (domain)، حتى تبقى حالة المصادقة متسقة في الجهتين.
الحليضبط Go API ملفات تعريف الارتباط بالسمتين HttpOnly وSameSite=Lax، ولا يتعامل تطبيق Next.js مع الرموز المميزة مباشرة؛ إذ يُتحقَّق من حالة المصادقة من جهة الخادم عند كل استدعاء API عبر GET /api/auth/me.
واجهة أمامية سبقت طبقة البيانات
المشكلةجميع واجهات المستخدم في الوحدات الـ12 مصمَّمة بالكامل ومبنية بهيكلها الأساسي، لكن جداول قاعدة البيانات التشغيلية ومعالجات API لم تُنشأ بعد. ويجب أن تبقى الواجهة الأمامية تعمل وقابلة للمراجعة دون بيانات حية.
الحلتستخدم كل واجهات الوحدات بيانات تجريبية ثابتة أثناء التطوير. وTanStack Query مربوط مسبقًا بوصفه طبقة جلب البيانات، فاستبدال البيانات التجريبية باستدعاءات API حية في المرحلة 6 لا يتطلب إعادة هيكلة الواجهة.

06 قبل وبعد

مقارنة بين الوضع قبل المشروع وبعده

قبل	بعد
لا نظام مصادقة: لا وصول مضبوط إلى أي جزء من المنصة	المصادقة تعمل من طرف إلى طرف: POST /api/auth/login وPOST /api/auth/logout وGET /api/auth/me، بجلسات قائمة على ملفات تعريف الارتباط مشتركة بين Go API وNext.js
لا مسار تدقيق: لا سجل يبيّن من غيّر ماذا ومتى	مخطط audit_log غير قابل للتغيير وقيد التشغيل: سجل للإضافة فقط (append-only) يرصد كل تغيير في النظام مع المُنفِّذ والتاريخ والوقت وبيانات الكيان
لا مخطط قاعدة بيانات للكيانات التشغيلية: العقارات والمستأجرون والملاك والفواتير والعقود بلا جداول	مخططات PostgreSQL مصمَّمة لكل الكيانات، وقد رُحِّلت بالفعل الجداول staff وaudit_log وfeed_items وsettings (اكتملت المرحلة 3)
لا تحكم في الوصول استنادًا إلى الدور: لا حدود للصلاحيات بين أدوار الموظفين	وسيط RequireRole مبني ومدمج في موجّه Go، وبانتظار التفعيل على كل المسارات المحمية
لا واجهة أمامية لأي سير عمل تشغيلي	جميع واجهات المستخدم في الوحدات الـ12 مصمَّمة بالكامل ومبنية بهيكلها الأساسي: الطلبات والعقارات والمستأجرون والملاك والعقود والفواتير والمدفوعات والمعاينات والرسائل والإدارة

وحدة العقود: إنشاء عقود الإيجار والتوقيع الإلكتروني. مصمَّمة بالكامل ومبنية بهيكلها الأساسي، وتصلها طبقة البيانات في المرحلة 4.

07 فوائد العميل ونتائجه

ما القيمة التي حصل عليها العميل؟

وحدة مصمَّمة: 12; من 12 مكتملة
مسار المصادقة: يعمل; Go ↔ Next.js
جداول قيد التشغيل: 4; staff · audit_log · feed_items · settings
نقاط نهاية نشطة: 3; تسجيل الدخول · تسجيل الخروج · الملف الشخصي

مصادقة من طرف إلى طرف منذ اليوم الأول
يعمل مسار المصادقة الكامل: نقاط نهاية تسجيل الدخول وتسجيل الخروج والملف الشخصي فعّالة، مع جلسات قائمة على ملفات تعريف ارتباط HttpOnly مشتركة بين Go API وواجهة Next.js الأمامية.
مسار تدقيق متوافق مع متطلبات الأمان مدمج في النظام
مخطط audit_log يعمل فعليًا ويقبل الإضافة فقط، ويرصد كل تغيير في النظام مع المُنفِّذ والتاريخ والوقت وبيانات الكيان، فيستوفي متطلبات الامتثال الأمني منذ أول ترحيل.
إعدادات مرنة على مستوى النظام كله
يتيح جدول settings المعتمد على JSONB إعدادات عامة وأخرى خاصة بالعقار وبالمستأجر من مخطط واحد، من دون الحاجة إلى جداول إضافية مع نمو متطلبات الإعدادات.
الواجهة الأمامية جاهزة، وطبقة البيانات قيد التنفيذ
جميع واجهات المستخدم في الوحدات الـ12 مصمَّمة بالكامل ومبنية بهيكلها الأساسي، وTanStack Query مربوط مسبقًا بوصفه طبقة البيانات. وفي المرحلة 6 تُربط بيانات API الحية دون الحاجة إلى إعادة هيكلة الواجهة الأمامية.

وحدة الفواتير: الفوترة والملخصات المالية، مصمَّمة بالكامل ومبنية بهيكلها الأساسي. وتصل طبقة البيانات في المرحلة 4.

08 الدروس المستفادة

ماذا تعلّمنا من هذا المشروع؟

يولّد sqlc شيفرة Go آمنة الأنواع من SQL
يأخذ sqlc استعلامات SQL ويولّد هياكل Go ودوال استعلام آمنة عند التصريف. وتظهر تغييرات المخطط في صورة أخطاء تصريف بدل أعطال وقت التشغيل.
يجمع مستودع واحد (monorepo) بين Go API وواجهة Next.js الأمامية
تعني بنية المستودع الواحد المتكاملة أن الواجهتين الخلفية والأمامية تتشاركان قاعدة شيفرة واحدة وبيئة تطوير واحدة ومسار نشر واحدًا.
بُنيت المصادقة واكتملت قبل أي ميزة تشغيلية
اكتملت المصادقة، بنقاط نهاية تسجيل الدخول وتسجيل الخروج والملف الشخصي، في المرحلة 3. ويُبنى كل تطوير لاحق على نموذج جلسات حي يعمل فعليًا.
صُمِّمت واجهات الوحدات الـ12 كلها قبل وجود قاعدة البيانات
بنينا هيكل الواجهة الأمامية كاملًا ببيانات تجريبية ثابتة قبل وجود أي مخطط قاعدة بيانات تشغيلي. وفي المرحلة 6 تحلّ استدعاءات TanStack Query الحية محل البيانات التجريبية، من دون إعادة هيكلة الواجهة.
يتيح JSONB في جدول settings إعدادات عامة وأخرى خاصة بالعقار وبالمستأجر
يعتمد مخطط settings على تصميم قائم على JSONB لحفظ الإعدادات على ثلاثة مستويات في جدول واحد: إعدادات المنصة العامة، وتجاوزات خاصة بكل عقار، وتجاوزات خاصة بكل مستأجر.