۰۱
اول مالکیت، بعد اشتراک
یک قابلیت زمانی مشترک میشود که مسئولیت و مالک عملیاتی آن روشن باشد. قوانین کسبوکار و داده مرجع هر دامنه در مالکیت همان محصول باقی میمانند.
اصول مهندسی
قواعد مشترک، برای اینکه استقلال محصول به پراکندگی تبدیل نشود.
محصولات پردازش ابری روباه نقرهای مسیر توسعه مستقل دارند، اما این استقلال در چارچوب قواعد مشترک برای مالکیت، قراردادها، امنیت، مشاهدهپذیری و مدیریت تغییر تعریف میشود.
این اصول شعار نیستند؛ محدودیتهای طراحی و عملیاتاند. کمک میکنند استفاده مجدد آگاهانه باشد، وابستگیها پنهان نمانند و مسئولیت هر بخش مشخص بماند.
۰۲
قرارداد، مرز ارتباط سیستمهاست
API، قراردادهای داده و قواعد سازگاری نسخهبندی میشوند تا نقطه اتصال سیستمها روشن باشد. یکپارچهسازی نباید به جزئیات داخلی پیادهسازی سرویس دیگر وابسته شود.
۰۳
پیشفرض امن، دسترسی صریح
هویت، مجوزدهی، زمینه مستأجر، مدیریت اطلاعات محرمانه و شواهد ممیزی در مرزهای قابل اعتماد طراحی میشوند. دسترسی بیشتر باید آگاهانه اعطا و با تغییر سیستم بازبینی شود.
۰۴
تغییر باید قابل مشاهده باشد
تحویل، دادههای عملیاتی و بازیابی یک چرخه بازخورد واحدند. تغییر زمانی از نظر عملیاتی کامل است که بتوان رفتار آن را با سیگنالهای مفید توضیح داد.
۰۵
معماری با شواهد تکامل پیدا میکند
پیچیدگی فقط وقتی وارد سیستم میشود که مقیاس، قابلیت اتکا یا نیاز واقعی محصول آن را توجیه کند. با تغییر شواهد، اجزا میتوانند جدا، جایگزین یا متمرکز شوند.
۰۶
RTL و LTR دو حالت همارز محصولاند
بومیسازی، تایپوگرافی، جهت، دسترسپذیری و رفتار واکنشگرا از ابتدا جزئی از محصولاند؛ نه مرحلهای برای ترجمه در پایان توسعه.
اصل مهندسی
هماهنگی باید از استقلال محصول محافظت کند، نه جای آن را بگیرد.
قواعد مشترک مهندسی مرزها را قابل پیشبینی میکنند تا محصولات مستقل تغییر کنند، بدون اینکه یکپارچهسازی و عملیات غیرقابل پیشبینی شود.