معماری سیستم

معماری‌ای که هزینه تغییر را پایین نگه می‌دارد.

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

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

۰۱

هر دامنه، یک مسئولیت روشن

مدل داده، منطق کسب‌وکار و چرخه توسعه هر دامنه صاحب مشخص دارد. زیرساخت مشترک به معنی منطق مشترک نیست.

مالکیت روشن دامنهانتشار مستقلپرهیز از ساخت قابلیت‌های تکراری
۰۲

قرارداد پیش از وابستگی

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

OpenAPI برای رابط‌های هم‌زمانAsyncAPI برای رویدادهاالگوی خطای یکپارچه برای API
۰۳

ماژولار تا وقتی توزیع‌شدن لازم شود

یک سرویس زمانی جدا می‌شود که مقیاس، ایزوله‌سازی، نوع بار کاری یا مالکیت عملیاتی واقعاً آن را توجیه کند؛ نه برای پر کردن نمودار معماری.

۰۴

تغییر، بخشی از طراحی است

سازگاری با نسخه‌های قبلی، مهاجرت داده و مسیر تفکیک اجزا از ابتدا در نظر گرفته می‌شوند تا رشد سیستم نیازمند بازنویسی کامل نباشد.

دیدگاه مهندسی

معماری خوب، حق انتخاب آینده را حفظ می‌کند.

سیستم امروز باید ساده و قابل فهم باشد و برای فردا هم مسیر قابل اتکایی برای رشد داشته باشد.