پیوست: پرسش‌های بحث

فصل ۱: مقدمه

  1. چهار بُعدی که معماری نرم‌افزار را تعریف می‌کنند کدام‌اند؟
  2. تفاوت تصمیم معماری (architecture decision) با اصل طراحی (design principle) چیست؟
  3. هشت انتظار اصلی از یک معمار نرم‌افزار را فهرست کنید.
  4. قانون اول معماری نرم‌افزار (First Law of Software Architecture) چیست؟

فصل ۲: تفکر معماری

  1. سه معیار نام ببرید که با آن‌ها بتوان تعیین کرد یک تصمیم بیشتر به معماری مربوط است یا به طراحی.
  2. سه سطح دانش را در مثلث دانش (هرم دانش) (knowledge triangle) فهرست کنید و برای هر یک مثالی بیاورید.
  3. چرا برای معمار، تمرکز بر گستردگی فنی (technical breadth) مهم‌تر از ژرفای فنی (technical depth) است؟
  4. برخی از راه‌های حفظ ژرفای فنی و درگیر ماندن مستقیم با کار فنی در مقام معمار کدام‌اند؟

فصل ۳: ماژولاریتی

  1. تفاوت ماژولاریتی (modularity) و دانه‌بندی (granularity) را شرح دهید و برای هر یک مثالی بیاورید.
  2. تفاوت کوپلینگ (coupling) و انسجام (cohesion) چیست؟
  3. اصطلاح هم‌بستگی (connascence) به چه معناست؟
  4. تفاوت هم‌بستگی ایستا (static connascence) و هم‌بستگی پویا (dynamic connascence) چیست؟
  5. قوی‌ترین شکل هم‌بستگی کدام است؟
  6. ضعیف‌ترین شکل هم‌بستگی کدام است؟
  7. در یک پایگاه کد، کدام‌یک ترجیح دارد: هم‌بستگی ایستا یا پویا؟

فصل ۴: تعریف ویژگی‌های معماری

  1. یک خصیصه برای آنکه ویژگی معماری (architecture characteristic) به شمار آید، باید کدام سه معیار را برآورده کند؟
  2. تفاوت ویژگی نامشهود (implicit characteristic) با ویژگی صریح (explicit characteristic) چیست؟ برای هر یک مثالی بیاورید.
  3. مثالی از یک ویژگی عملیاتی (operational characteristic) بیاورید.
  4. مثالی از یک ویژگی ساختاری (structural characteristic) بیاورید.
  5. مثالی از یک ویژگی میان‌بُرشی (cross-cutting characteristic) بیاورید.
  6. چرا تهیهٔ فهرستی استاندارد و فراگیر در سطح صنعت از ویژگی‌های معماری ناممکن است؟

فصل ۵: شناسایی ویژگی‌های معماری

  1. دلیلی بیاورید که چرا محدود کردن شمار ویژگی‌هایی («‎-ilities‎») که یک معماری باید از آن‌ها پشتیبانی کند، رویهٔ خوبی است.
  2. درست یا نادرست؟ بیشتر ویژگی‌های معماری از الزامات کسب‌وکار و داستان‌های کاربری (user stories) سرچشمه می‌گیرند.
  3. اگر یک ذی‌نفع کسب‌وکار اعلام کند که زمان عرضه به بازار (time to market)—یعنی رساندن هرچه سریع‌تر قابلیت‌های تازه و رفع اشکال‌ها به دست کاربران—مهم‌ترین دغدغهٔ کسب‌وکار است، معماری باید از کدام ویژگی‌های معماری پشتیبانی کند؟
  4. تفاوت مقیاس‌پذیری (scalability) و کشسانی (elasticity) چیست؟
  5. تعریف ویژگی معماری مرکب (composite architectural characteristic) چیست؟ یک مثال بیاورید.

فصل ۶: سنجش و حاکمیت بر ویژگی‌های معماری

  1. چرا پیچیدگی چرخه‌ای (cyclomatic complexity) سنجه‌ای چنین مهم برای تحلیل معماری است؟
  2. توابع برازش معماری (architecture fitness functions) چیستند؟ چگونه می‌توان از آن‌ها برای تحلیل یک معماری استفاده کرد؟
  3. مثالی از یک تابع برازش معماری برای سنجش مقیاس‌پذیری یک معماری بیاورید.
  4. مهم‌ترین معیار برای یک ویژگی معماری، تا معماران و توسعه‌دهندگان بتوانند برای آن توابع برازش بسازند، چیست؟

فصل ۷: دامنهٔ ویژگی‌های معماری

  1. کوانتوم معماری (architectural quantum) چیست و چرا برای معماری اهمیت دارد؟
  2. سیستمی را فرض کنید که از یک رابط کاربری واحد و چهار سرویسِ مستقل‌مستقرشونده تشکیل شده و هر سرویس پایگاه‌دادهٔ جداگانهٔ خودش را دارد. این سیستم یک کوانتوم دارد یا چهار کوانتوم؟ چرا؟
  3. تفاوت کوپلینگ ایستا (static coupling) و کوپلینگ پویا (dynamic coupling) چیست؟ برای هر یک مثالی بیاورید.
  4. چرا ارتباط هم‌گام (synchronous) در مقایسه با ارتباط ناهم‌گام (asynchronous) اثر بالقوهٔ بزرگ‌تری بر ویژگی‌های عملیاتی معماری دارد؟

فصل ۸: تفکر مؤلفه‌محور

  1. ما اصطلاح مؤلفه (component) را به‌عنوان یکی از بلوک‌های سازندهٔ برنامهٔ کاربردی تعریف می‌کنیم؛ یعنی کاری که برنامه انجام می‌دهد. یک مؤلفه معمولاً از گروهی از کلاس‌ها یا فایل‌های منبع تشکیل می‌شود. مؤلفه‌ها معمولاً در یک برنامهٔ کاربردی یا سرویس به چه شکلی نمود می‌یابند؟
  2. تفاوت افراز فنی (technical partitioning) و افراز حوزه‌ای (domain partitioning) چیست؟ برای هر یک مثالی بیاورید.
  3. مزیت افراز حوزه‌ای چیست؟
  4. در چه شرایطی افراز فنی انتخاب بهتری از افراز حوزه‌ای است؟
  5. تلهٔ موجودیت (Entity Trap) چیست؟ چرا رویکرد خوبی برای شناسایی مؤلفه‌ها نیست؟
  6. هنگام شناسایی مؤلفه‌های اصلی، چه زمانی ممکن است رویکرد گردش‌کار (Workflow approach) را بر رویکرد کنشگر/کنش (Actor/Action approach) ترجیح دهید؟

فصل ۹: مبانی

  1. هشت مغالطهٔ محاسبات توزیع‌شده (fallacies of distributed computing) را فهرست کنید.
  2. سه چالش نام ببرید که معماری‌های توزیع‌شده دارند و معماری‌های تک‌پارچه ندارند.
  3. کوپلینگ مُهری (stamp coupling) چیست؟ برخی از راه‌های رسیدگی به کوپلینگ مُهری کدام‌اند؟
  4. تفاوت افراز فنی و افراز حوزه‌ای چیست؟
  5. سه ویژگی را فهرست کنید که یک سبک معماری (architectural style) را از یک الگو (pattern) متمایز می‌کنند.

فصل ۱۰: سبک معماری لایه‌ای

  1. تفاوت لایهٔ باز (open layer) و لایهٔ بسته (closed layer) چیست؟
  2. مفهوم لایه‌های جداسازی (layers of isolation) و مزایای آن را شرح دهید.
  3. ضدالگوی چاهک معماری (Architecture Sinkhole antipattern) چیست؟
  4. برخی از ویژگی‌های اصلی معماری که شما را به استفاده از معماری لایه‌ای سوق می‌دهند کدام‌اند؟
  5. چرا سبک معماری لایه‌ای از آزمون‌پذیری (testability) به‌خوبی پشتیبانی نمی‌کند؟
  6. چرا سبک معماری لایه‌ای از چابکی (agility) به‌خوبی پشتیبانی نمی‌کند؟

فصل ۱۱: سبک معماری تک‌پارچهٔ ماژولار

  1. تک‌پارچهٔ ماژولار (modular monolith) چه تفاوتی با معماری لایه‌ای چندلایه (n-tiered layered architecture) دارد؟
  2. تفاوت رویکرد همتابه‌همتا (peer-to-peer) و رویکرد میانجی (mediator) را در ارتباط میان ماژول‌ها شرح دهید.
  3. سه ریسک رایج مرتبط با سبک معماری تک‌پارچهٔ ماژولار کدام‌اند؟
  4. سه نقطهٔ قوت اصلی تک‌پارچهٔ ماژولار را نام ببرید و بگویید چه زمانی باید استفاده از آن را در نظر بگیرید.
  5. با وجود ماژولاریتیِ تک‌پارچهٔ ماژولار، چرا ویژگی‌های عملیاتی‌ای مانند مقیاس‌پذیری و تحمل خطا (fault tolerance) در آن وضع خوبی ندارند؟

فصل ۱۲: سبک معماری خط لوله

  1. آیا لوله‌ها (pipes) در معماری خط لوله (pipeline architecture) می‌توانند دوسویه باشند؟
  2. چهار نوع فیلتر (filter) و هدف هر یک را نام ببرید.
  3. آیا یک فیلتر می‌تواند داده را از طریق چند لوله به بیرون بفرستد؟
  4. توضیح دهید چرا معماری خط لوله برای محیط‌های مبتنی بر ابر مناسب است.
  5. آیا سبک معماری خط لوله به‌صورت فنی افراز شده است یا به‌صورت حوزه‌ای؟
  6. معماری خط لوله به چه شکلی از ماژولاریتی پشتیبانی می‌کند؟

فصل ۱۳: سبک معماری میکروکرنل

  1. نام دیگر سبک معماری میکروکرنل (microkernel architecture style) چیست؟
  2. در چه شرایطی اشکالی ندارد که مؤلفه‌های افزونه (plug-in components) به مؤلفه‌های افزونهٔ دیگر وابسته باشند؟
  3. برخی از ابزارها و چارچوب‌هایی که می‌توان از آن‌ها برای مدیریت افزونه‌ها استفاده کرد کدام‌اند؟
  4. اگر افزونه‌ای از یک شخص ثالث داشتید که با قرارداد استاندارد افزونه در سیستم هسته (core system) سازگار نبود، چه می‌کردید؟
  5. دو مثال از سبک معماری میکروکرنل بیاورید.
  6. کدام ویژگی‌های سیستم هسته میزان «میکروکرنل‌بودن» (microkern-ality) آن را تعیین می‌کنند؟
  7. چرا معماری میکروکرنل همیشه یک کوانتوم معماری واحد است؟
  8. هم‌ریختی حوزه و معماری (domain/architecture isomorphism) چیست؟

فصل ۱۴: سبک معماری مبتنی بر سرویس

  1. چرا سرویس‌ها در معماری مبتنی بر سرویس (service-based architecture)، سرویس‌های حوزه‌ای (domain services) نامیده می‌شوند؟
  2. دو ریسک رایج مرتبط با معماری مبتنی بر سرویس را نام ببرید.
  3. از کدام توپولوژی‌های پایگاه‌داده (تک‌پارچه، حوزه‌ای و اختصاصی) می‌توانید در معماری مبتنی بر سرویس استفاده کنید؟
  4. برای مدیریت تغییرات پایگاه‌داده در یک معماری مبتنی بر سرویس از چه تکنیک‌هایی می‌توانید استفاده کنید؟
  5. آیا سرویس‌های حوزه‌ای برای اجرا به کانتینر (مانند Docker) نیاز دارند؟
  6. سبک معماری مبتنی بر سرویس از کدام ویژگی‌های معماری به‌خوبی پشتیبانی می‌کند؟
  7. چرا معماری مبتنی بر سرویس معمولاً از کشسانی به‌خوبی پشتیبانی نمی‌کند؟
  8. چگونه می‌توانید شمار کوانتوم‌های معماری را در یک معماری مبتنی بر سرویس افزایش دهید؟

فصل ۱۵: سبک معماری رویدادمحور

  1. چهار تفاوت میان رویدادها و پیام‌ها (messages) را نام ببرید.
  2. تفاوت رویداد آغازگر (initiating event) با رویداد مشتق (derived event) چیست؟
  3. رویداد سمی (poison event) چیست؟
  4. آیا یک پردازندهٔ رویداد (event processor) می‌تواند چند رویداد مشتق را راه‌اندازی کند؟ اگر چنین است، چرا ممکن است بخواهید این کار را انجام دهید؟
  5. چرا ممکن است از یک پردازندهٔ رویداد، رویدادی را راه‌اندازی کنید که هیچ پردازندهٔ رویداد دیگری به آن پاسخ نمی‌دهد؟
  6. برخی از مصالحه‌های منفی استفاده از پردازش ناهم‌گام کدام‌اند؟
  7. ضدالگوی دستهٔ پشه‌ها (Swarm of Gnats antipattern) را شرح دهید و توضیح دهید چرا باید از آن پرهیز کنید.
  8. دو دلیل اصلی بیاورید که چرا معماری رویدادمحور (event-driven architecture) بسیار پاسخ‌گوست و ویژگی‌های کارایی عالی دارد.
  9. برخی از تکنیک‌های جلوگیری از گم‌شدن داده (data loss) هنگام فرستادن پیام به صف و دریافت پیام از آن کدام‌اند؟

فصل ۱۶: سبک معماری مبتنی بر فضا

  1. نام معماری مبتنی بر فضا (space-based architecture) از کجا آمده است؟
  2. جنبهٔ اصلی معماری مبتنی بر فضا که آن را از دیگر سبک‌های معماری متمایز می‌کند چیست؟
  3. چهار مؤلفه‌ای را نام ببرید که میان‌افزار مجازی‌شده (virtualized middleware) را در معماری مبتنی بر فضا تشکیل می‌دهند.
  4. نقش نویسندهٔ داده (data writer) در معماری مبتنی بر فضا چیست؟
  5. در چه شرایطی یک سرویس باید از طریق خوانندهٔ داده (data reader) به داده‌های پایگاه‌داده دسترسی یابد؟
  6. آیا اندازهٔ کوچک کش احتمال برخورد داده (data collision) را افزایش می‌دهد یا کاهش؟
  7. تفاوت کش تکثیرشده (replicated cache) با کش توزیع‌شده (distributed cache) چیست؟ معمولاً کدام‌یک در معماری مبتنی بر فضا به کار می‌رود؟
  8. سه ویژگی معماری را فهرست کنید که معماری مبتنی بر فضا به قوی‌ترین شکل از آن‌ها پشتیبانی می‌کند.
  9. چرا آزمون‌پذیری در معماری مبتنی بر فضا رتبهٔ بسیار پایینی دارد؟

فصل ۱۷: معماری سرویس‌گرای ارکستراسیون‌محور

  1. نیروی محرکهٔ اصلی پشت معماری سرویس‌گرا (service-oriented architecture) چه بود؟
  2. چهار نوع اصلی سرویس در معماری سرویس‌گرا کدام‌اند؟
  3. برخی از عواملی را که به افول معماری سرویس‌گرا انجامیدند فهرست کنید.
  4. آیا SOA به‌صورت فنی افراز شده است یا به‌صورت حوزه‌ای؟
  5. بازاستفادهٔ حوزه (domain reuse) در SOA چگونه مدیریت می‌شود؟ بازاستفادهٔ عملیاتی (operational reuse) چطور؟
  6. کاربرد اصلی این سبک معماری در سیستم‌های امروزی چیست؟

فصل ۱۸: معماری میکروسرویس‌ها

  1. مفهوم زمینهٔ محدود (bounded context) را در میکروسرویس‌ها شرح دهید. چرا این مفهوم برای معماری‌های میکروسرویس چنین حیاتی است؟
  2. چرا جداسازی داده (data isolation) در معماری میکروسرویس‌ها چنین اهمیتی دارد؟
  3. شرح دهید منظور از همکنش‌پذیریِ ناهمگونِ آگاه از پروتکل (protocol-aware heterogeneous interoperability) چیست و میکروسرویس‌ها چگونه از آن پشتیبانی می‌کنند.
  4. تفاوت ارکستراسیون (orchestration) و کرئوگرافی (choreography) در میکروسرویس‌ها چیست؟ برای هر یک از این سبک‌های ارتباطی، مثالی بیاورید که در آن انتخاب مناسبی باشد.
  5. چرا میکروسرویس‌ها از توپولوژی پایگاه‌داده به ازای هر سرویس (database-per-service) استفاده می‌کنند؟ آیا می‌توانند از توپولوژی پایگاه‌دادهٔ تک‌پارچه یا حوزه‌ای استفاده کنند؟
  6. دو مورد از بزرگ‌ترین ریسک‌های معماری میکروسرویس‌ها کدام‌اند؟
  7. چرا میکروسرویس‌ها از چابکی، آزمون‌پذیری و استقرارپذیری (deployability) چنین به‌خوبی پشتیبانی می‌کنند؟
  8. سه دلیل بیاورید که چرا کارایی معمولاً در میکروسرویس‌ها مسئله‌ساز است.
  9. توپولوژی‌ای را شرح دهید که در آن یک اکوسیستم میکروسرویس ممکن است تنها یک کوانتوم داشته باشد.

فصل ۱۹: انتخاب سبک معماری مناسب

  1. معماری داده (data architecture) یک سیستم (یعنی ساختار مدل‌های دادهٔ منطقی و فیزیکی) به چه شکلی بر انتخاب سبک معماری شما اثر می‌گذارد؟
  2. گام‌هایی را که معمار برای تعیین سبک معماری، افراز داده و سبک‌های ارتباطی یک سیستم برمی‌دارد، به تفکیک شرح دهید.
  3. کدام عامل معمار را به سوی معماری توزیع‌شده سوق می‌دهد؟
  4. معماری برای انتخاب سبک معماری مناسب باید کدام دو تحلیل ورودی را انجام دهد؟

فصل ۲۰: الگوهای معماری

  1. دو الگو نام ببرید که دغدغهٔ معماریِ جداسازی دغدغه‌های عملیاتی و حوزه‌ای را پیاده می‌کنند.
  2. گردش‌کار ارکستره‌شده کدام مؤلفه را دارد که در گردش‌کارهای کرئوگرافی‌شده وجود ندارد؟
  3. برخی از مزایای استفاده از یک کارگزار (broker) واحد در معماری رویدادمحور کدام‌اند؟ برخی از معایب آن کدام‌اند؟
  4. CQRS کدام دو عملیات داده را از هم جدا می‌کند؟

فصل ۲۱: تصمیمات معماری

  1. ضدالگوی «خود را پوشش بده» (Covering Your Assets antipattern) چیست؟
  2. برخی از تکنیک‌های پرهیز از ضدالگوی «معماری ایمیل‌محور» (Email-Driven Architecture antipattern) کدام‌اند؟
  3. پنج عاملی که Michael Nygard برای تشخیص اینکه چیزی دارای اهمیت معماری (architecturally significant) است تعریف می‌کند، کدام‌اند؟
  4. پنج بخش پایهٔ سابقهٔ تصمیم معماری (architecture decision record) کدام‌اند؟
  5. معمولاً توجیه یک تصمیم معماری را در کدام بخش ADR می‌افزایید؟
  6. با این فرض که به بخش جداگانهٔ «گزینه‌های جایگزین» نیازی ندارید، گزینه‌های جایگزین راه‌حل پیشنهادی‌تان را در کدام بخش ADR فهرست می‌کنید؟
  7. سه سناریوی پایه‌ای که در آن‌ها وضعیت یک ADR را پیشنهادی (Proposed) علامت می‌زنید کدام‌اند؟

فصل ۲۲: تحلیل ریسک معماری

  1. دو بُعد ماتریس ارزیابی ریسک (risk assessment matrix) کدام‌اند؟
  2. سه فعالیت اصلی طوفان ریسک (risk storming) را شرح دهید.
  3. چرا طوفان ریسک باید تمرینی مشارکتی باشد؟
  4. چرا فعالیت شناسایی در طوفان ریسک باید فعالیتی فردی باشد و نه مشارکتی؟
  5. اگر سه شرکت‌کننده ریسک بخش خاصی از معماری را بالا (۶) ارزیابی کنند، اما شرکت‌کنندهٔ دیگری آن را تنها متوسط (۳) بداند، چه می‌کنید؟
  6. به فناوری‌های اثبات‌نشده یا ناشناخته چه رتبهٔ ریسکی (۱ تا ۹) می‌دهید؟

فصل ۲۳: نمودارکشی معماری

  1. دلبستگی نامعقول به مصنوع (irrational artifact attachment) چیست و چرا در مستندسازی و نمودارکشی معماری اهمیت دارد؟
  2. چهار C (4 Cs) در تکنیک مدل‌سازی C4 کدام‌اند؟
  3. هنگام نمودارکشی معماری، خطوط نقطه‌چین میان مؤلفه‌ها چه معنایی دارند؟
  4. چرا گنجاندن عنوان و راهنما (key) در نمودار معماری همیشه مهم است؟

فصل ۲۴: اثربخش کردن تیم‌ها

  1. سه نوع شخصیت معمار کدام‌اند؟ هر شخصیت چه نوع مرزی پدید می‌آورد؟
  2. برای تعیین میزان مشارکت خود با تیم، کدام پنج عامل را باید در نظر بگیرید؟
  3. سه نشانهٔ هشدار که تیم شما بیش از حد بزرگ شده است کدام‌اند؟
  4. سه فهرست وارسی (checklist) پایه را فهرست کنید که استفاده از آن‌ها برای تیم توسعه مفید است.

فصل ۲۵: مهارت‌های مذاکره و رهبری

  1. چرا مذاکره (negotiation) مهارتی چنین مهم برای معمار است؟
  2. برای سناریویی که در آن یک ذی‌نفع کسب‌وکار بر در دسترس‌بودنِ «پنج نُه» پافشاری می‌کند، اما در واقع تنها «سه نُه» لازم است، چند تکنیک مذاکره نام ببرید.
  3. از اینکه یک ذی‌نفع کسب‌وکار به شما می‌گوید «دیروز لازمش داشتم» چه نتیجه‌ای می‌توانید بگیرید؟
  4. چرا تکنیک نمایش عملی بر بحث چیره می‌شود (demonstration defeats discussion) چنین اثربخش است؟
  5. قاعدهٔ «تفرقه بینداز و حکومت کن» (divide and conquer) چیست؟ چگونه می‌توان آن را هنگام مذاکره دربارهٔ ویژگی‌های معماری با یک ذی‌نفع کسب‌وکار به کار برد؟ مثالی بیاورید.
  6. چهار C معماری (4 Cs of architecture) را فهرست کنید.
  7. توضیح دهید چرا برای معمار مهم است که هم عمل‌گرا (pragmatic) باشد و هم دوراندیش (visionary).
  8. برخی از تکنیک‌های مدیریت و کاهش شمار جلساتی که به آن‌ها دعوت می‌شوید کدام‌اند؟

فصل ۲۶: تقاطع‌های معماری

  1. برای اطمینان از همسویی ساختاری با معماری در طول پیاده‌سازی، از چه تکنیک‌هایی می‌توانید استفاده کنید؟
  2. توضیح دهید چرا همسو کردن معماری و زیرساخت چنین اهمیتی دارد و مثالی از این همسویی بیاورید.
  3. مثالی بیاورید از زمانی که توپولوژی یک تیم ممکن است با معماری همسو نباشد.
  4. چرا معمارِ مسئول یک سیستم خاص باید دغدغهٔ تقاطع معماری و یکپارچه‌سازی سیستم‌ها (systems integration) را داشته باشد؟ مثالی بیاورید از جایی که معماری ممکن است با یکپارچه‌سازی سیستم‌ها ناهمسو شود.
  5. هم‌ریختی حوزه و معماری چیست و چرا هنگام بررسی تقاطع معماری و کسب‌وکار چنین اهمیتی دارد؟
  6. مثالی از تقاطع معماری و سازمان بیاورید.

فصل ۲۷: بازنگری در قوانین معماری نرم‌افزار

  1. سه مزیت عام کتابخانهٔ مشترک (shared library) نسبت به سرویس مشترک (shared service) را فهرست کنید. آیا این مزایا به این معناست که معمار هرگاه با این مصالحه روبه‌رو شد، باید همیشه کتابخانهٔ مشترک را برگزیند؟
  2. نتیجهٔ فرعی اول قانون اول معماری نرم‌افزار چیست؟
  3. چرا نتیجهٔ فرعی دوم قانون اول معماری نرم‌افزار تأکید می‌کند که تحلیل مصالحه باید بارها و بارها انجام شود؟
  4. چرا بسیاری از تصمیمات معماری نرم‌افزار را بهتر است بر یک طیف درک کنیم تا به‌صورت دوگانه‌هایی آسان و دم‌دستی؟

واژه‌نامهٔ اختصاصی این پیوست

واژهٔ انگلیسی معادل مصوب/به‌کاررفته در این پیوست
Discussion Questionsپرسش‌های بحث
Architecture Decisionتصمیم معماری (جمع: تصمیمات معماری)
Design Principleاصل طراحی (جمع: اصول طراحی)
First Law of Software Architectureقانون اول معماری نرم‌افزار
Knowledge Triangleمثلث دانش (هرم دانش)
Technical Breadthگستردگی فنی
Technical Depthژرفای فنی
Granularityدانه‌بندی
Cohesionانسجام
Connascenceهم‌بستگی
Static Connascenceهم‌بستگی ایستا
Dynamic Connascenceهم‌بستگی پویا
Implicit Architecture Characteristicویژگی نامشهود معماری
Explicit Architecture Characteristicویژگی صریح معماری
Cross-Cutting Architectural Characteristicsویژگی‌های میان‌بُرشی معماری
Time to Marketزمان عرضه به بازار
Composite Architectural Characteristicویژگی معماری مرکب
Cyclomatic Complexityپیچیدگی چرخه‌ای
Architectural Fitness Functionتابع برازش معماری
Architecture Quantum (pl. Quanta)کوانتوم معماری (ج. کوانتوم‌ها)
Technical Partitioningافراز فنی
Domain Partitioningافراز حوزه‌ای
Entity Trapتلهٔ موجودیت
Fallacies of Distributed Computingمغالطه‌های محاسبات توزیع‌شده
Stamp Couplingکوپلینگ مُهری
Layers of Isolationلایه‌های جداسازی
Architecture Sinkhole (antipattern)چاهک معماری
Modular Monolithتک‌پارچهٔ ماژولار
Pipeline Architectureمعماری خط لوله
Microkernel Architectural Styleسبک معماری میکروکرنل
Core Systemسیستم هسته
Domain/Architecture Isomorphismهم‌ریختیِ حوزه و معماری
Service-Based Architectureمعماری مبتنی بر سرویس
Domain Serviceسرویس حوزه‌ای
Messageپیام
Initiating Eventرویداد آغازگر
Derived Eventرویداد مشتق
Poison Eventرویداد سمی
Event Processorپردازندهٔ رویداد
Swarm of Gnats Antipatternضدالگوی دستهٔ پشه‌ها
Event-Driven Architectureمعماری رویدادمحور
Data Lossگم‌شدن داده
Space-Based Architectureمعماری مبتنی بر فضا
Virtualized Middlewareمیان‌افزار مجازی‌شده
Data Writerنویسندهٔ داده
Data Readerخوانندهٔ داده
Data Collisionبرخورد داده
Replicated Cacheکش تکثیرشده
Distributed Cacheکش توزیع‌شده
Domain Reuseبازاستفادهٔ حوزه
Operational Reuseبازاستفادهٔ عملیاتی
Bounded Contextزمینهٔ محدود
Data Isolationجداسازی داده
Protocol-Aware Heterogeneous Interoperabilityهمکنش‌پذیریِ ناهمگونِ آگاه از پروتکل
Database-per-Serviceپایگاه‌داده به ازای هر سرویس
Deployabilityاستقرارپذیری
Data Architectureمعماری داده
Brokerکارگزار
Covering Your Assets (antipattern)ضدالگوی «خود را پوشش بده»
Email-Driven Architecture (antipattern)ضدالگوی «معماری ایمیل‌محور»
Architecturally Significantدارای اهمیت معماری
Proposed (ADR status)پیشنهادی
Risk Assessment Matrixماتریس ارزیابی ریسک
Risk Stormingطوفان ریسک
Irrational Artifact Attachment (antipattern)دلبستگی نامعقول به مصنوع
Key (legend)راهنما
Checklistفهرست وارسی
Negotiationمذاکره
Demonstration Defeats Discussionنمایش عملی بر بحث چیره می‌شود
Divide and Conquerتفرقه بینداز و حکومت کن
4 Cs of Architectureچهار C معماری
Pragmaticعمل‌گرا
Visionaryدوراندیش
Systems Integrationیکپارچه‌سازی سیستم‌ها