پرش به مطلب اصلی

نمونهٔ موجودیت

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

نمونه​

{
  "schema": "barsa.definition.v1",
  "project": {
    "code": "SAMPLE",
    "caption": "Sample",
    "systemId": "${RESOLVE_SYSTEM_ID}",
    "version": "1.0.0"
  },
  "references": {},
  "artifacts": [
    {
      "kind": "entity",
      "code": "Customer",
      "caption": "Customer"
    }
  ]
}

آنچه این نمونه نشان می‌دهد​

  • موجودیت به‌صورت مصنوع نمایش داده می‌شود.
  • مصنوع در آرایهٔ ریشهٔ artifacts قرار می‌گیرد.
  • نوع مصنوع صریحاً entity اعلام می‌شود.
  • شناسه‌های پایدار تألیف مانند code باید آگاهانه انتخاب شوند.
  • متن خواندنی برای انسان، مانند caption، باید از هویت ماشینی جدا بماند.

آنچه این نمونه ثابت نمی‌کند​

این نمونه ثابت نمی‌کند که همهٔ عملیات ممکنِ موجودیت در سطح تألیف فعلی در دسترس‌اند. پیش از ایجاد یا تغییر موجودیت واقعی بررسی کنید:

  1. Native Barsa رفتار موردنظر موجودیت را پشتیبانی می‌کند.
  2. Runtime از عملیات موردنظر پشتیبانی می‌کند.
  3. BDL می‌تواند ساختار لازم را بیان کند.
  4. سطح فعلی تألیف BDL عملیات را مجاز می‌داند.

گسترش موجودیت​

موجودیت‌های واقعی معمولاً به تعریف‌های بیشتری مانند فیلدها، روابط، قیدها، مجوزها، فرم‌ها یا مصنوعات مرتبط نیاز دارند. این موارد را فقط با ساختارهای مستند نسخهٔ مبنای فعال BDL اضافه کنید.

ساختار مستندنشدۀ فیلد را از این نمونهٔ حداقلی استنباط نکنید.

الگوی تألیف ایمن​

با کوچک‌ترین تعریف قابل اعتبارسنجی موجودیت شروع کنید. سپس فیلدها و مصنوعات مرتبط را تدریجی اضافه کنید و هر تغییر معنادار را اعتبارسنجی کنید؛ مدل بزرگ و بررسی‌نشده را یک‌باره تولید نکنید.

موجودیت‌های موجود​

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

ادامه​

نمونهٔ بعدی ارتباط مصنوع فرم با موجودیت را توضیح می‌دهد.