رفتن به محتوای اصلی
مصطفی عفتی

درباره این پلتفرم

دفتر کاری زنده برای تجربه‌های مهندسی

این پلتفرم مهندسی شخصی مصطفی عفتی است؛ جایی برای تبدیل تجربه عملی به نوشتار روشن، یادگیری ساختاریافته و محصولات دیجیتال کاربردی.

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

  • خانم زهرا احسانی

    دانشجوی سابق · مشارکت‌کننده در توسعه پلتفرم

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

اینجا چه پیدا می‌کنید

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

با طراحی آگاهانه

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

این پلتفرم پیوسته در حال تکامل است. بعضی بخش‌ها محصولاتی کامل‌اند و برخی دیگر آزمایش‌های فعالی که هم‌زمان با پیشرفت کار بهتر می‌شوند.

Organizations و Location

مدل‌سازی Organization، Employee و geo به‌عنوان domain entity — نه فیلدهای free-text چسبیده به User.
Mostafa Effati3 دقیقه مطالعهsoftware-architecture

Organization و Location مال Identityاند

وقتی Person و User Account جدا شدند، عضویت سازمانی دیگر شبیه یک boolean روی ردیف profile نیست.

یک نفر می‌تواند Employee یک شرکت، contractor شرکت دیگر و customer سومی باشد — در حالی که یک یا چند User Account دارد. Location هم «رشتهٔ address روی User» نیست: Device، آدم و Org همه در geography می‌نشینند.

این فصل لایهٔ Context کتاب است: کسی در کار کیست، و چیزها کجا رخ می‌دهند.

Organization یک User با flag نیست

Organization lifecycle خودش را دارد: industry، type، legal name، tax id، parent org برای hierarchy، status history.

Organization
 ├── parent (optional hierarchy)
 ├── industry / type
 ├── legal identity fields
 └── status + history

Employee رابطهٔ Person و Organization است — با position، department، بازهٔ hire، و contactهای محدود به Org.

این همان درس Citizenship است: membership یک relationship Aggregate است، نه فقط organization_id تا ابد روی Person.

چرا Employee Contact جداست

Work email و work phone همان channelهای personal روی User Account نیستند. مدل Organization-Employee Contact مرز verify و افشا را وقتی کسی شرکت را ترک می‌کند سالم نگه می‌دارد.

Location به‌عنوان Domain، نه ستون متن

Geo در این سرویس ساخت‌یافته است:

لایهنقش
Country / subdivision / cityReference data
LocationEntity نقطه‌مانند با coordinates رمزشده
Search / proximity tokenBlind lookup بدون plaintext coords در index
نشانه‌های geo در Device SessionRisk و context، نه address book دوم

Device Session می‌تواند به country، subdivision و city ارجاع دهد. Location مختصات رمزشده به‌علاوهٔ search token (مختصات گردشده، proximity hash) نگه می‌دارد تا قابلیت «near me» لازم نباشد دنیا را در هر query decrypt کند.

این چه چیزی را جلوگیری می‌کند

میان‌برصورتحساب بعدی
company_name روی usersMerger، legal name، چند نهاد employer
یک فیلد متن addressNormalization، privacy، proximity search
Role فقط در claimهای JWTبدون تاریخچهٔ hire/leave، بدون درخت Org
Org خیلی زود در سرویس دیگرSplit-brain Identity برای همان انسان

Status History به‌عنوان الگو

Person، Contact، Session، Organization، Employee — خیلی از Aggregateها status به‌علاوهٔ جدول history دارند که با الگوی trigger مشترک جلو می‌رود. Identity فقط ردیف فعلی نیست؛ چرا و کی state عوض شده هم هست.

این برای KYC، support و تحقیقات امنیتی مهم‌تر از صفحهٔ profile قشنگ است.

برداشت

Identity جایی است که ساختار دنیای واقعی به system access می‌رسد. Organization و geography بخشی از آن ساختارند. پرت‌کردنشان به‌عنوان فکر بعدی، دوباره جدول تخت users را می‌سازد — فقط با JSON بیشتر.

بعد

Backend می‌تواند درست باشد و محصول هنوز بشکند اگر Edge دو لایهٔ cookie را بد مدیریت کند. فصل آخر Frontend Session Edge است.

ادامه: Frontend Session Edge.

اسناد مرتبط

منوی دستور

↑ ↓برای حرکت · Enter برای انتخاب · Esc برای بستن
ناوبری
اقدامات

Esc برای بستن · ⌘K برای باز/بسته کردن