مروری بر چند موضوع متنوع در زمینه معماری نرم افزار

1) Infrastructure as Code (IaC)

یعنی برای پیاده سازی زیرساخت‌های فناوری اطلاعات به جای اینکه به طور دستی کامپیوترها یا سرورها را تنظیم کنیم یا نصب نرم افزارها را انجام دهیم این کارها را با نوشتن کد انجام می‌دهیم. مثلا برای یک وب سایت می‌خواهیم چند سرور جدید بسازیم این کار را می‌توانیم به صورت کد بنویسیم به این صورت که بنویسیم چه سرورهایی می‌خواهیم و چه پیکربندی‌هایی باید داشته باشند. سپس به یکی از ابزارهای IaCمثلا Terraformارسال کنیم. این ابزار به طور خودکار سرورها را ایجاد و پیکربندی می‌نماید. این کار سریع تر است چون پیکربندی‌ها به صورت خودکار و نه دستی انجام می‌شود و همینطور خطای انسانی کمتری دارد. همچنین برای سرورهای جدید در آینده هم می‌توان از کدهای قبلی استفاده کرد یا تغییرات کوچکی در آن اعمال کرد و به همین صورت با سرعت و دقت بیشتر سرورهای جدید را راه اندازی کرد.

2) API Gateway & Service Mesh

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

Service Mesh یک لایه نرم افزاری است که ارتباطات بین میکروسرویس‌ها را مدیریت می‌کند بدون اینکه در کد آن‌ها دخالت کنند. به طور خودکار درخواست‌ها را به صورت امن بین سرویس‌ها هدایت می‌کند. بنابراین هم به امنیت ارتباط میان سرویس‌ها کمک می‌کند و هم در نظارت بر ترافیک جابه جا شده بین سرویس‌ها نقش دارد.

3) CQRS (Command Query Responsibility Segregation)

یک الگوی طراحی است که هدف اصلی آن جداسازی دستورات از کوئری‌ها می‌باشد. دستورات یعنی عملیاتی که اطلاعات را تغییر می‌دهند مثل write، delete، update و create. کوئری عملیاتی هستند که اطلاعات را تغییر نمی‌دهند مثل read. در این الگو برخلاف معماری نرم افزار معمولی، این دو عمل کاملا از هم جدا می‌شوند. این جداسازی کمک می‌کند تا بتوانیم هرکدام از دو عمل را به طور مستقل بهینه سازی کنیم. همچنین در مقیاس پذیری کمک می‌کند مثلا با توجه به اینکه عمل خواندن بسیار بیشتر از نوشتن و ... انجام می‌شود می‌توان سیستم را طوری مقیاس بندی کرد که ظرفیت خواندن بسیار بیشتر باشد بدون اینکه در ظرفیت نوشتن تغییری ایجاد شود. همچنین این الگو این امکان را می‌دهد که بتوانیم از پایگاه داده‌های مختلف برای انجام این دو عمل استفاده کنیم. ساختار این الگو به این صورت است که معمولا دستورات به یک سرویس خاص که مسئول انجام تغییر در سیستم است ارسال می‌شود و کوئری‌ها به یک سرویس یا API دیگر ارسال می‌شود که به طور خاص برای خواندن با سرعت بیشتر بهینه سازی شده است. در این الگو ما به دو مدل داده جداگانه نیاز داریم که سنکرون کردن آن‌ها خودش پیچیدگی و هزینه خواهد داشت.

استفاده از CQRS مزایای خاص خود را دارد، اما باید با دقت و در شرایط مناسب به کار گرفته شود، زیرا می‌تواند پیچیدگی و ریسک زیادی ایجاد کند. CQRS باید تنها در بخش‌های خاصی از سیستم استفاده و نه در کل سیستم. همچنین، برای سیستم‌هایی که مناسب CQRS نیستند، می‌توان از Reporting Database برای مدیریت پرس‌و‌جوهای پیچیده استفاده کرد.

4) Event-Driven Architecture (EDA)

یک الگوی طراحی است که در آن سیستم‌ها بر اساس رویدادها عمل می‌کنند. رویداد هر تغییری است که در سیستم رخ می‌دهد مثلا ارسال یک پیام یا تغییر وضعیت یک رکورد. سیستم یک Event Producer دارد که هر زمان که یک تغییر در سیستم رخ می‌دهد، آن را به عنوان یک Eventمنتشر می‌کند. سپس Event Consumer رویداد را دریافت و پردازش می‌کند. مثلا داده را ذخیره می‌کند یا به دیگر اجزا ارسال می‌کند. رویدادها از طریق کانال رویداد (Event Channel) از تولیدکننده رویداد به مصرف کننده آن منتقل می‌شوند.

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

5) Serverless Architecture

یک الگوی طراحی است که در آن نیازی به مدیریت و نگهداری سرورها نیست و منابع محاسباتی به صورت خودکار توسط ارائه دهندگان سرویس‌های ابری مدیریت می‌شوند و توسعه دهندگان تنها کد خود را می‌نویسند و آن را به سرویس ابری ارسال می‌کنند. یک مدل این معماری فراخوانی تابع Faas(Function as a service) است. این توابع به صورت خودکار توسط سرویس‌های ابری اجرا می‌شوند. مثلا وقتی یک درخواست HTTP به سرور ارسال می‌شود، یک تابع اجرا می‌شود.مدل BaaS(Backend as a Service) استفاده از سیستم‌های ابری برای ذخیره سازی داده‌ها، احراز هویت، ارسال ایمیل و ... است. یعنی به جای ساخت یک پایگاه داده از سرویس‌های آماده استفاده می‌کنیم. مزایای این سیستم علاوه بر عدم نیاز به مدیریت سیستم، مقیاس پذیری خودکار است. سیستم براساس تقاضا به صورت خودکار مقیاس می‌شود و همچنین هزینه‌ها براساس مصرف واقعی منابع محاسبه می‌شود.
از معایب این معماری محدودیت عملکرد، محدودیت ذخیره سازی و وابستگی به سرورهای ابری می‌باشد.

ابزارهای معروف:

· AWS Lambda

· Azure Functions

· Google Cloud Functions

· Firebase

6) API-first Approach

یک رویکرد در توسعه نرم افزار است که در آن طراحی و توسعه API در اولویت قرار می‌گیرد. در این رویکرد APIبخش اصبی هر اپلیکیشن یا سیستم است. ابتدا API به طور دقیق طراحی و مستند می‌شود و سپس تمام پیاده سازی سیستم‌ها و اپلیکیشن‌ها بر اساس آن انجام می‌شود. همچنین این رویکرد به تیم‌های Backend و Frontend این امکان را می‌دهد که به طور مستقل از هم کار کنند زیرا API مشخص و مستند است و تیم فرانت می‌تواند بدون نیاز به Backend به توسعه خود ادامه دهد و برعکس. یکی از مزایای این رویکرد این است که می‌توان سیستم‌ها را به راحتی مقیاس پذیر کرد و خدمات مختلف را به هم متصل کرد بدون این که تغییرات بزرگ در ساختار سیستم ایجاد شود. همچنین امکان تست API و در نتیجه شناسایی مشکلات در مراحل اولیه توسعه نرم افزار وجود دارد. از آنجایی که میکروسرویس‌ها معمولا با APIها با یکدیگر ارتباط برقرار می‌کنند این رویکرد برای معماری میکروسرویس‌ها مناسب می‌باشد.
یکی از معایب این روش این است که به دلیل مستندسازی دقیق API در ابتدا زمان بیشتری صرف می‌شود و اگر در ادامه تغییراتی در طراحی APIها نیاز باشد می‌تواند پرهزینه باشد. ابزارهایی مانند Swagger/OpenAPI یا RAML برای طراحی و مستندسازی APIها استفاده می‌شوند.

7) Domain Driven Design

طراحی مبتنی بر دامنه یا DDD یک رویکرد توسعه نرم افزار است که بر مدلسازی دامنه کسب و کار تمرکز دارند. تمام فرایندهای طراحی براساس مدل دامنه ساخته می‌شوند. در واقع هدف توسعه دهندگان این است که مفاهیم اصلی کسب و کار را به کد تبدیل کنند.
مدل دامنه شامل موجودیت ها(Entities)، Value Objects که معمولا برای توصیف ویژگی‌های موجودیت‌ها استفاده می‌شوند، سرویسها و قوانین دامنه(Domain Rules) می‌باشد.
در این روش سیستم به بخش‌های مختلفی به نام Bounded Context تقسیم می‌شود. که هرکدام زیرمجموعه‌ای از دامنه هستند و مدل دامنه و زبان خاص خود را می‌توانند داشته باشند.
Aggregateها مجموعه‌ای از موجودیت‌ها و Value Objects هستند که به هم مرتبط هستند و به عنوان یک واحد برای تغییر داده عمل می‌کنند. مثلا حساب بانکی می‌تواند یک Aggregate باشد که شامل تراکنش و موجودی است.
روش DDDبرای پروژه‌های کوچک می‌تواند بیش از حد پیچیده باشد و همچنین نیاز به همکاری مداوم بین تیم‌های مختلف دارد که در بعضی پروژه‌ها ممکن است سخت باشد.طراحی مدل‌های دقیق دامنه و تقسیم به Bounded Contextها می‌تواند زمانبر و پر هزینه باشد. در نتیجه این روش برای سیستم‌های بزرگ با دامنه‌های کسب و کار پیچیده مفید است.

8) Hexagonal Architecture

یک الگوی طراحی معماری نرم افزار است که به Architectural Ports and Adapters نیز شناخته می‌شود. هدف این روش جداسازی لایه‌های مختلف و ایجاد یک سیستم تمیز و قابل نگهداری است. در این معماری سیستم اصلی که به آن هسته یا Coreگفته می‌شود با استفاده از پورت‌ها و آداپتورها به دنیای خارج وصل می‌شود و با آن تعامل می‌کند یعنی سیستم هسته هیچ وابستگی به دنیای بیرون ندارد و این کمک میکند که منطق کسب و کار به راحتی تغییر و نگهداری شود. پورت‌ها مشخص می‌کنند که سیستم چه کارهایی را می‌تواند انجام دهد و چه داده‌هایی را می‌تواند خروجی دهد. آداپتور‌ها پورت‌ها را به اجزای خارجی یا سیستم‌های دیگر وصل می‌کنند. آداپتورها داده‌ها از یک فرمت یا سیستم را به فرمت یا سیستم دیگر تبدیل می‌کنند یعنی پورت‌های هسته‌ای را به تکنولوژی‌های مختلف وصل می‌کنند مثل APIها یا پایگاه داده.

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

· Spring Boot: پیاده سازی آداپتورها و پورت‌ها در سیستم‌های Java.

· Axon Framework: برای پیاده سازی معماری‌های پیچیده با استفاده از CQRS و Event Sourcing

9) Event Sourcing

یک الگوی معماری نرم افزار است که در آن وضعیت سیستم به صورت تاریخچه‌ای از Eventها ذخیره می‌شود. یعنی هر تغییری که در سیستم اتفاق می‌افتد به عنوان یک رویداد ثبت می‌شود و این رویدادها به ترتیب زمان در یک سیستم ذخیره می‌شوند و از آن‌ها می‌توان برای بازسازی وضعیت سیستم، تحلیل خطاها و بازگشت به وضعیت درست قبلی استفاده کرد.
از مزیت‌های مهم این روش این است که همیشه تاریخچه‌ای از تغییرات سیستم وجود دارد این در سیستم‌های مالی و بانکداری، سیستم‌های گزارش گیری که به زمان داده‌ها نیاز دارند، سیستم‌های توزیع شده و سیستم‌هایی که پیگیری تغییرات در آنها اهمیت بالایی دارد بسیار مفید است. همچنین امکان بازگشت به یک وضعیت قبلی می‌تواند در دیباگ کردن و بازسازی داده‌ها کاربردی باشد. همچنین در این روش داده‌ها به طور مستقیم تغییر نمی‌کنند و رویداد‌ها هستند که ذخیره می‌شوند بنابراین می‌تواند به مقیاس پذیر بودن سیستم کمک کند تا به تعداد بالایی از رویدادها رسیدگی کند.
این روش نیاز به طراحی دقیق مدیریت رویدادها دارد و چون تمام تغییرات به عنوان رویداد ذخیره می‌شوند می‌تواند حجم داده بالایی تولید کند که این در سیستم‌های بزرگ با عملیات پیچیده روی داده‌ها اگر معماری مناسب برای مدیریت رویدادها وجود نداشته باشد می‌تواند مشکلات مقیاس پذیری ایجاد کند.
ابزارهای مهم مرتبط:

· Axon Framework

· EventStore

· Kafka

· Apache Pulsar

10) Low-code/No-code platforms

ابزارها و پلتفرم‌هایی هستند که کاربران با استفاده از آنها می‌تواند بدون کدنویسی یا با حداقل کدنویسی و با استفاده از واسط‌های گرافیکی و قالب‌های آماده، نرم افزارها را طراحی و توسعه دهند. در low code کاربران می‌توانند بخش‌هایی از اپلیکیشن را کدنویسی کنند بنابراین کاربر می‌تواند اپلیکیشن‌های پیچیده و سفارشی را با این ابزارها بسازد. اما در no code کاربر بدون کدنویسی می‌تواند نرم افزار یا اپلیکیشن بسازد. این برای کاربرانی طراحی شده که هیچ تجربه‌ای در برنامه نویسی ندارند. این پلتفرم مناسب اپلیکیشن‌های ساده و کم حجم می‌باشد.

این پلتفرم‌ها قابلیت انتشار و بروزرسانی سریع را برای نرم افزار فراهم می‌کنند و روند توسعه نرم افزار را کوتاه تر می‌کنند. همچنین به راحتی قابلیت اتصال به سرویس‌های ابری، پایگاه‌های داده، APIها و ... را فراهم می‌کنند. این پلتفرم‌ها نیاز به توسعه دهندگان و دانش عمیق برنامه نویسی را کمتر می‌کند و در نتیجه هزینه توسعه نرم افزار را کاهش می‌دهد و از این رو برای کسب و کار‌های کوچک یا استارت آپ‌ها مناسب می‌باشد.
از معایب این روش‌ها وابستگی به پلتفرم و محدودیت سفارشی سازی است. تغییر نرم افزار به شکلی که پلتفرم آن را پشتیبانی نمی‌کند، ممکن نیست و تغییر پلتفرم هم می‌تواند مشکل ساز باشد. از طرفی به لحاظ امنیتی ذخیره داده‌ها و کدهای حساس در پلتفرم‌های ابری ممکن است مشکلاتی برای کسب و کار ایجاد کند و نیاز به تدابیر امنیتی اضافه دارد.
چند نمونه از این پلتفرم‌ها:

· Bubble: پلتفرم no-codeبرای اپلیکیشن‌های وب

· OutSystems: پلتفرم low-codeبرای اپلیکیشن‌های سازمانی و وب

· AppGyver: پلتفرم no-codeبرای ساخت اپلیکیشن موبایل و وب

· Mendix: پلتفرم low-code برای ساخت اپلیکیشن‌های سازمانی

· Wix: پلتفرم no-codeبرای طراحی وب سایت‌های ساده

· Microsoft PowerApps: پلتفرم low-code برای اپلیکیشن‌های سازمانی

11) Business Process Management Systems (BPMS)

سیستم‌های مدیریت فرآیند کسب وکار، نرم افزارهایی هستند که به سازمان‌ها کمک می‌کنند تا فرآیندهای کسب و کار خود را مدل سازی، پیاده سازی و بهینه کنند. مدل سازی گرافیکی فرآیند کسب و کار به تیم توسعه کمک می‌کند تا درک بهتری از جریان کار سیستم پیدا کنند. همچنین BPMS این امکان را فراهم می‌کند که مراحل تکراری یا برخی پردازش‌ها به صورت خودکار انجام شود تا خطا کاهش یابد. BPMSقابلیت یکپارچگی با سیستم‌های دیگر مانند ERP، CRM و پایگاه داده‌ها را دارد و باعث هماهنگی بیشتر بین سیستم‌های مختلف یک سازمان می‌شود.
برای مثال یک بانک می‌خواهد درخواست و تایید وام را برای مشتریان بهبود دهد. با استفاده از BPMS ابتدا فرآیند درخواست وام مدلسازی می‌شود. سپس این فرایند خودکار می‌شود. به این صورت که مثلا اگر مشتری درخواست وام دارد اطلاعات او جمع آوری و توسط سیستم اعتبارسنجی می‌شود و در صورت تایید به مدیر ارسال می‌شود. وقتی مدیر وام را تایید کند به صورت خودکار به مشتری اطلاع رسانی می‌شود. به این صورت مدیران می‌توانند فرآِیندهای درخواست‌ها را به سادگی نظارت و مدیریت کنند و با استفاده از گزارش‌هایی که BPMSتولید می‌کند نقاط قوت و ضعف سیستم را شناسایی کنند و در آینده آنها را بهینه تر کنند.
استفاده از BPMS به سازمان‌ها امکان خودکار کردن فرآیند‌های دستی، نظارت بهتر بر انجام آنها و بهبود تصمیم گیری، کاهش خطاهای انسانی و افزایش سرعت پردازش فرآیند‌ها را می‌دهد. البته پیاده سازی BPMS در سازمان‌های بزرگ و فرآیندهای پیچیده نیاز به زمان و منابع برای طراحی و یکپارچگی سیستم‌ها دارد و هزینه‌های نصب و راه اندازی آن ممکن است برای سازمان‌های کوچک مقرون به صرفه نباشد. همچنین برای استفاده موثر از آن کارکنان سازمان باید با سیستم جدید آشنا شوند و آموزش ببینند. همچنین یکپارچگی BPMS با دیگر سیستم‌ها و نرم افزارهای سازمان می‌تواند مشکلات نگهداری و به روزرسانی ایجاد کند.
پلتفرم‌های معروف BPMS:

· Bizagi

· Pega

· Appian

· Activiti

12) Message Queue (such as Kafka and RabbitMQ)

Massage Queueها یا صف‌های پیام سیستم‌هایی هستند که برای ارسال و دریافت پیام بین اجزای مختلف سیستم استفاده می‌شوند. آن‌ها به اعضای مختلف یک سیستم امکان ارتباط به صورت مستقل از هم و غیرهمزمان را می‌دهند. یعنی ارسال کننده پیام می‌تواند پیام را ارسال کند بدون اینکه منتظر دریافت پیام باشد و گیرنده در زمان مناسب می‌تواند پیام را پردازش کند. پیام‌ها به صورت مستقل از هم ارسال می‌شوند و گیرنده نیازی به دانستن جزئیات ارسال کننده ندارد و این موجب کاهش وابستگی بین اجزای مختلف سیستم می‌شوند. از اینرو Message Queueها به ویژه در سیستم‌های توزیع شده و معماری میکروسرویس‌ها کاربرد دارد. اجزای سیستم میتوانند پیام‌ها را به صورت پشت سر هم یا به صورت batch پردازش کنند و این سرعت پردازش حجم بالای پیام را بیشتر می‌کند. صف‌های پیام طوری طراحی می‌شوند که بتوانند در برابر حجم بالای پیام‌ها عملکرد خوبی داشته باشند و مقیاس پذیر باشند. بسیاری از آن‌ها مانند Kafka درصورت بروز خطا، قابلیت بازیابی دارند و پیام‌ها از دست نمی‌روند.

Appache Kafka یک پلتفرم توزیع شده است که در ابتدا به عنوان یک سیستم Message Queueساخته شد اما به مرور به یک پلتفرم جریان داده تبدیل شده که برای پردازش و ذخیره سازی داده‌ها در زمان واقعی طراحی شده است. پیام‌های ارسال شده در Kafkaبرای مدت معینی ذخیره می‌مانند و می‌توانند توسط اجزای مختلف به صورت همزمان خوانده شوند.

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

13) Container orchestration (such as Kubernetes)

به فرآیند خودکارسازی مدیرت، استقرار و نظارت بر کانتینرهای نرم افزاری گفته می‌شود. Kubernetes یکی از ابزارهای محبوب این کار است که به سازمان‌ها کمک می‌کند تا تعداد زیادی کانتینر را مدیریت کنند. توسعه دهندگان با استفاده از orchestration می‌توانند به راحتی برنامه‌های خود را در محیط‌های مختلف استقرار دهند. این کار با ایجاد، حذف و بروزرسانی کانتینرها انجام می‌شود. بار ترافیک به طور خودکار بین کانتینر‌ها توزیع می‌شود تا در یک کانتینر ترافیک زیاد ایجاد نشود. اگر یکی از کانتینر‌های خراب شود سیستم آن را شناسایی کرده و یک کانتینر دیگر جایگزین می‌کند. همچنین این ابزارها امکان نظارت بر کانتینرها در زمان واقعی و ثبت و جمع آوری لاگ‌ها برای پیداکردن مشکلات را می‌دهند.

Docker Swarm یکی دیگر از این ابزارهاست که مشابه Kubernetesاست اما پیچیدگی آن کمتر و پیاده سازی راحت تری دارد و برای محیط‌های کوچکتر مناسبتر می‌باشد.

14) Multi-Tenancy Architecture

یک الگوی طراحی نرم افزاری است که در آن یک نمونه از برنامه یا سیستم می‌تواند به طور همزمان به چند Tenant خدمت رسانی کند. هر Tenant یک واحد مجزا است که می‌تواند یک سازمان یا کاربر یا یک تیم باشد و داده‌ها و رفتارهای خاص خود را داشته باشد. در این معماری منابع نرم افزاری و سخت افزاری مانند پایگاه داده‌ها، سرور‌ها، پروسسور‌ها و ... بین چندین Tenant به اشتراک گذاشته می‌شود اما هر Tenant از نظر داده‌ها تنظیمات مجزا از بقیه است. این معماری به ویژه در سیستم‌هایی که نیاز به مقیاس پذیری دارند مانند SaaSها مناسب است زیرا می‌توان تعداد زیادی Tenant را با کمترین هزینه و منابع مدیریت کرد. جداسازی داده‌ها در این معماری می‌تواند به صورت شبیه سازی پایگاه داده‌ها یا تخصیص محیط‌های مجازی و ... انجام شود. سیستم معمولا از یک نقطه مرکزی برای مدیریت و پیکربندی تمام Tenantها استفاده می‌کند که این موجب راحتی نگهداری و به روزرسانی سیستم می‌شود. یکی از نکات مهم این معماری این است که باید اطمینان حاصل شود که منابع به رستی به Tenantهای مختلف تخصیص داده شود و هیچ کدام از Tenantها نباید به داده‌های دیگری دسترسی داشته باشد.

نحوه ذخیره سازی داده‌ها و منابع می‌تواند در معماری‌های مختلف متفاوت باشد سه نوع رایج آن به صورت زیر می‌باشد:

· Shared Database, Shared Schema: استفاده از یک پایگاه داده و داده‌های هر Tenant با یک TenantID از هم جدا می‌شوند.

· Shared Database, Separate Schema: یک پایگاه داده اما برای هر Tenant یک شمای جداگانه تعریف می‌شود.

· Separate Database: هر Tenant یک پایگاه داده جدا دارد.

استفاده از این معماری به دلیل به اشتراک گذاشتن منابع موجب کاهش هزینه می‌شود. همچنین با افزایش تعداد Tenantها می‌توان سیستم را مقیاس پذیر کرد. این معماری با جداسازی داده‌های هر Tenant می‌تواند امنیت بالایی فراهم کند.
نرم افزارهای SaaS، سیستم‌های بزرگ مانند Google و Microsoft 365 که به ده‌ها هزار مشتری خدمات می‌دهند، پلتفرم‌های ابری که تعداد زیادی از مشتریان را با منابع مشترک میزبانی می‌کنند، سیستم‌های مدیریت مشتریCRM و سیستم‌های ERP که به کسب و کارهای مختلف خدمات می‌دهند از این معماری استفاده می‌کنند.

15) Enterprise Integration Patterns:

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

الگوهای Message Routing به جابه جایی و مسیریابی صحیح پیام‌ها بین سیستم‌های مختلف کمک می‌کنند. مثلا Conditional Routing الگویی است که بر اساس شرایط خاص یا منطقی داده‌ها مسیر پیام را مشخص می‌کند. الگوهای تبدیل پیام برای تبدیل و پردازش پیام‌ها در حین حرکت از یک سیستم به سیستم دیگر طراحی شده‌اند مثلا Message Translatorفرمت پیام‌ها را تغییر می‌دهد مثلا داده‌های XML را به JSONتغییر می‌دهد. الگوهای Message Endpoint به نحوه ارسال و دریافت پیام‌ها از سیستم‌ها می‌پردازد. الگوهای Integration Styles به نوع ادغام سیستم‌ها و روش‌های برقراری ارتباط بین آن‌ها اشاره دارند. مثلا در روش Point-to-Point Integration دو سیستم به طور مستقیم با یکدیگر ارتباط برقرار می‌کنند. در Hub-and-Spoke Integration چندین سیستم از طریق یک هاب مرکزی به هم متصل می‌شوند و هاب مسئول هدایت پیام‌ها به سیستم‌های مقصد است. در Brokered Integration از یک پیام رسان مرکزی برای مدیریت پیام‌ها و توزیع آن‌ها بین سیستم‌ها استفاده می‌شود.

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