معماری ماژولار چیست و چه زمانی به کار می‌آید؟

یک نرم‌افزار در روز اول معمولاً ساده است.

چند صفحه.

چند جدول.

چند API.

یک تیم کوچک هم روی آن کار می‌کند.

بعد محصول رشد می‌کند.

فروش اضافه می‌شود.

انبار.

پرداخت.

گزارش.

اعلان.

کاربران.

سطوح دسترسی.

یکپارچه‌سازی با سیستم‌های دیگر.

و چند سال بعد، تغییری کوچک در «سفارش» باعث می‌شود تیم نگران باشد که شاید بخش مالی، انبار یا گزارش‌گیری هم خراب شود.

مشکل الزاماً بزرگ‌شدن نرم‌افزار نیست.

مشکل این است که مرزهای داخل آن دیگر روشن نیستند.

اینجاست که معماری ماژولار اهمیت پیدا می‌کند.

ایده اصلی ساده است:

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

Microsoft در اصول معماری خود این هدف را با دو مفهوم مهم توضیح می‌دهد:

High Cohesion و Loose Coupling.

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

معماری ماژولار قبل از اینکه درباره Server، Container یا Kubernetes باشد، درباره همین مرزهاست.

«ماژولار» الزاماً یعنی Microservices؟

نه.

این یکی از مهم‌ترین تفاوت‌هاست.

یک Application می‌تواند به‌صورت یک واحد Deploy شود، اما داخل Codebase به بخش‌های مشخص و نسبتاً مستقل تقسیم شده باشد.

Microsoft در راهنمای معماری Web Application توضیح می‌دهد که یک Monolithic Application می‌تواند از چند Library، Component یا Layer تشکیل شده باشد، اما همچنان به‌صورت یک واحد Deploy شود. همچنین تأکید می‌کند که Monolith بودن الزاماً به معنی Code سازمان‌نیافته نیست.

این مدل را معمولاً:

Modular Monolith

می‌نامیم.

مثلاً یک سیستم فروش ممکن است ماژول‌های زیر را داشته باشد:

• Customers
• Orders
• Inventory
• Payments
• Reporting
• Notifications

اما همه آن‌ها هنوز داخل یک Application قرار دارند و با یک Deployment منتشر می‌شوند.

مرزها منطقی‌اند، نه لزوماً شبکه‌ای.

Modular Monolith چیست؟

Modular Monolith تلاش می‌کند سادگی عملیاتی یک Monolith را با نظم معماری یک سیستم ماژولار ترکیب کند.

به زبان ساده:

یک Deployment، چند مسئولیت جدا.

فرض کنید سیستم فروش چنین ساختاری دارد:

Customers

Orders

Inventory

Payments

هر ماژول:

مسئولیت مشخصی دارد.

Business Ruleهای خودش را نگه می‌دارد.

Interface مشخصی برای ارتباط با بقیه دارد.

و قرار نیست بخش‌های دیگر آزادانه وارد جزئیات داخلی آن شوند.

اما همه ماژول‌ها هنوز داخل یک Process یا Application اصلی اجرا می‌شوند.

Microsoft نیز Modular Monolith را به‌عنوان انتخابی عمل‌گرایانه میان Monolith ساده و Microservices مطرح کرده و اشاره می‌کند که Microservices با وجود مزایای Scaling و Flexibility، پیچیدگی بیشتری وارد سیستم می‌کند.

این مدل برای بسیاری از پروژه‌ها نقطه شروع بسیار منطقی‌تری از Microservices است.

پس Microservices چه تفاوتی دارد؟

در Microservices، مرزها فقط داخل Code نیستند.

هر بخش می‌تواند یک Application یا Service مستقل باشد.

مثلاً:

Order Service

Inventory Service

Payment Service

Customer Service

هرکدام ممکن است:

Repository خودش را داشته باشد.

Runtime خودش را داشته باشد.

Database خودش را مدیریت کند.

مستقل Deploy شود.

مستقل Scale شود.

و حتی توسط Team جداگانه‌ای توسعه داده شود.

Microsoft Microservices را مجموعه‌ای از Serviceهای کوچک، مستقل و Loosely Coupled تعریف می‌کند که از طریق APIهای مشخص با هم ارتباط دارند و می‌توانند جداگانه Deploy و Scale شوند.

همین استقلال مزیت اصلی Microservices است.

و تقریباً منبع اصلی پیچیدگی آن هم همین است.

معماری منطقی و Deployment Architecture را یکی نگیرید

فرض کنید در تحلیل Domain به این نتیجه رسیده‌ایم که:

Ordering

Inventory

و:

Payment

سه Bounded Context متفاوت هستند.

آیا حتماً باید سه Container و سه Service مستقل بسازیم؟

نه.

Microsoft صریحاً می‌گوید Logical Architecture و Physical Architecture الزاماً یک‌به‌یک نیستند.

یک Bounded Context ممکن است از نظر Domain مرز مستقل داشته باشد، اما تصمیم فیزیکی درباره اینکه به یک Service، چند Service یا بخشی از یک Deployment تبدیل شود، مسئله دیگری است.

این موضوع کمک می‌کند معماری را بر اساس Business Domain طراحی کنیم، نه بر اساس ابزار.

ابتدا مرزها.

بعد Deployment.

نه برعکس.

مرز ماژول را از Business پیدا کنید، نه Folder Structure

فرض کنید Code را به این پوشه‌ها تقسیم کنیم:

Controllers

Services

Repositories

Models

آیا سیستم ماژولار شده؟

نه لزوماً.

این فقط Technical Layering است.

در یک Application بزرگ‌تر، مرزهای ارزشمندتر معمولاً از Business Capability می‌آیند.

مثلاً:

• Sales
• Purchasing
• Inventory
• Shipping
• Billing
• Customer Support

AWS در راهنمای Decomposition پیشنهاد می‌کند سیستم‌ها بر اساس Business Capability یا Subdomain شکسته شوند؛ یعنی بر اساس کاری که کسب‌وکار انجام می‌دهد، نه صرفاً نوع Technology داخل Code.

این تفاوت مهم است.

چون Business Capabilityها معمولاً عمر بیشتری از Framework و Database Technology دارند.

Bounded Context چه کمکی می‌کند؟

یکی از مفاهیم مهم Domain-Driven Design، Bounded Context است.

فرض کنید مفهوم «مشتری» را داریم.

در CRM، Customer ممکن است شامل این اطلاعات باشد:

• نام
• شماره تماس
• Industry
• Lead Source
• Sales Representative
• Customer Segment

اما در بخش سفارش، شاید فقط نیاز داریم:

• Customer ID
• Delivery Address
• Credit Status

در بخش پشتیبانی هم تعریف دیگری از Customer مهم است.

تلاش برای ساخت یک Customer Model جهانی که تمام نیازهای همه بخش‌ها را پوشش دهد، معمولاً به Model بسیار پیچیده‌ای منجر می‌شود.

Bounded Context می‌گوید هر بخش می‌تواند Domain Model خودش را داشته باشد.

Microsoft این الگو را روشی برای شکستن Complexity بزرگ به Contextهای مستقل می‌داند که هرکدام Vocabulary، Model و Boundary مشخصی دارند.

یعنی:

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

باید در Context خودش معنی درستی داشته باشد.

High Cohesion یعنی چه؟

High Cohesion یعنی چیزهایی که متعلق به یک مسئولیت‌اند کنار هم باشند.

مثلاً قوانین:

• ثبت سفارش
• تغییر وضعیت سفارش
• محاسبه وضعیت سفارش
• لغو سفارش

احتمالاً باید نزدیک یکدیگر و داخل همان Domain قرار بگیرند.

اگر بخشی از منطق Order در:

Controller

بخشی در Inventory Service

بخشی در Utility مشترک

و بخشی در Report Module

پخش شده باشد، تغییر Business Rule سفارش سخت می‌شود.

Microsoft پیشنهاد می‌کند Functionهایی که معمولاً با هم تغییر می‌کنند در یک Service یا Module قرار بگیرند.

به زبان ساده:

چیزهایی که با هم تغییر می‌کنند، بهتر است کنار هم زندگی کنند.

Loose Coupling یعنی چه؟

Loose Coupling یعنی Module A برای تغییرکردن، تا جای ممکن مجبور نباشد Module B را هم تغییر دهد.

مثلاً Order Module باید بداند:

«موجودی این کالا قابل رزرو است؟»

اما لازم نیست بداند Inventory دقیقاً:

چه Tableهایی دارد،

چه Queryهایی اجرا می‌کند،

یا چه Libraryای استفاده می‌کند.

بهتر است Inventory یک Contract مشخص داشته باشد.

Microsoft نیز برای Microservices توصیه می‌کند ارتباط بین بخش‌ها از طریق API یا Contract مشخص انجام شود و Implementation Detail به بیرون نشت نکند.

همین اصل داخل Modular Monolith هم ارزشمند است.

حتی اگر Call هنوز داخل یک Process انجام می‌شود.

اگر همه Moduleها مستقیم Database همدیگر را تغییر دهند، مرز واقعی نداریم

فرض کنید Order Module می‌تواند مستقیم Table موجودی را Update کند.

Inventory هم Table سفارش را می‌خواند.

Reporting Business Ruleهای Payment را داخل SQL خودش دوباره پیاده کرده است.

روی Diagram چهار ماژول داریم.

در واقع یک سیستم به‌شدت Coupled داریم.

Google در راهنمای تازه Modularization خود که در اوت ۲۰۲۶ به‌روزرسانی شده، Data Isolation را یکی از عناصر مهم Modularization می‌داند و هشدار می‌دهد Shared Data Access می‌تواند باعث Tight Coupling، مشکل Fault Isolation و Performance Bottleneck شود.

در Modular Monolith الزاماً لازم نیست هر ماژول Server Database جداگانه داشته باشد.

اما یک قاعده عملی خوب این است:

مالکیت Data مشخص باشد.

یعنی مثلاً:

Orders مالک داده سفارش است.

بقیه Moduleها نباید بدون Contract مشخص Business Data آن را دستکاری کنند.

مرز واقعی در رفتار Code دیده می‌شود، نه فقط در Folder Name.

ارتباط زیاد میان دو ماژول می‌تواند نشانه مرز اشتباه باشد

فرض کنید Order Module برای انجام هر Request مجبور است:

چهار بار Inventory را صدا بزند.

سه بار Pricing.

دو بار Customer.

و بعد Payment.

و هر تغییر در Inventory نیازمند Update هم‌زمان Order باشد.

شاید مشکل Communication Technology نیست.

شاید مرزهای Domain اشتباه‌اند.

Microsoft اشاره می‌کند که ارتباط بیش از حد یا نیاز به تغییر هماهنگ چند Service می‌تواند نشانه Tight Coupling و Low Cohesion باشد.

قبل از اضافه‌کردن Kafka، RabbitMQ یا API Gateway بهتر است بپرسیم:

آیا این دو چیز اصلاً باید جدا باشند؟

یک سیستم را بیش از حد خرد نکنید

Microservices کوچک هستند.

اما «هر Function یک Microservice» طراحی خوبی نیست.

Microsoft توصیه می‌کند از Serviceهای بیش از حد Granular پرهیز شود، چون تعداد زیاد Serviceها Complexity و Communication Cost را افزایش می‌دهد.

AWS هم هشدار می‌دهد Decomposition بر اساس Subdomain می‌تواند در صورت افراط تعداد Microserviceها را بیش از حد زیاد کند و Service Discovery و Integration را دشوار کند.

اگر برای ثبت یک سفارش ساده ۱۵ Service باید از طریق Network با هم صحبت کنند، احتمال دارد معماری بیشتر از مسئله اصلی پیچیده شده باشد.

هدف Modularity بیشترین تعداد قطعه نیست؛ بهترین مرزهاست.

Microservices رایگان نیست

مزایای Microservices جذاب‌اند:

• Independent Deployment
• Independent Scaling
• Fault Isolation
• Team Autonomy
• Technology Flexibility

اما هر Service جدید چیزهای دیگری هم اضافه می‌کند:

• Service Discovery
• Network Failure
• Timeout
• Retry
• Distributed Tracing
• API Versioning
• Message Broker
• Eventual Consistency
• Secrets
• Deployment Pipeline
• Container
• Monitoring
• Alerting
• Service Ownership
• و Debugging توزیع‌شده

Microsoft صریحاً می‌گوید Microservices پیچیدگی قابل‌توجهی در Service Discovery، Data Consistency و مدیریت سیستم‌های توزیع‌شده ایجاد می‌کنند و برای موفقیت به Development و DevOps maturity بالاتری نیاز دارند.

AWS نیز Distributed Architecture را همراه با Trade-offهایی مثل Latency، Debugging دشوارتر و افزایش Operational Complexity معرفی می‌کند.

پس Microservices فقط یک معماری Code نیست.

یک مدل عملیاتی جدید است.

Monolith همیشه انتخاب بدی نیست

واژه Monolith گاهی طوری استفاده می‌شود که انگار خودش یک Bug است.

اما این نگاه دقیق نیست.

Microsoft در راهنمای Modern Web Applications می‌گوید در بسیاری از شرایط، یک Application واحد بسیار ساده‌تر از مجموعه‌ای از Serviceهای مستقل ساخته، Deploy و Debug می‌شود و همچنان می‌تواند تمام Business Requirementها را پوشش دهد.

همچنین توضیح می‌دهد هزینه و پیچیدگی Microservices در بعضی پروژه‌ها می‌تواند بیشتر از منفعت آن باشد.

AWS نیز اشاره می‌کند که برای Applicationهای کوچک تا متوسط، Distributed Architecture الزاماً برتر از Monolithic Architecture نیست؛ مخصوصاً وقتی تعداد Teamها کم است و سیستم هنوز با مشکل Coupling یا Release Lead Time جدی روبه‌رو نشده است.

انتخاب معماری مسابقه مدرن‌بودن نیست.

باید مشکل واقعی را حل کند.

چه زمانی Modular Monolith انتخاب خوبی است؟

Modular Monolith می‌تواند گزینه مناسبی باشد وقتی:

تیم هنوز کوچک است

اگر پنج Developer دارید، راه‌اندازی و نگهداری ۳۰ Service ممکن است بیشتر از Development اصلی وقت بگیرد.

Domain در حال شکل‌گیری است

در ابتدای محصول ممکن است هنوز دقیق ندانیم مرز Business Capabilityها کجاست.

تغییر Boundary داخل یک Codebase معمولاً ساده‌تر از تغییر شبکه‌ای چند Service مستقل است.

Independent Scaling نیاز اصلی نیست

اگر تقریباً تمام Application رفتار Scaling مشابهی دارد، جداسازی فیزیکی ممکن است منفعت زیادی نداشته باشد.

Deployment مستقل حیاتی نیست

اگر Featureها معمولاً با هم Release می‌شوند و تیم واحد مالک کل Product است، Single Deployment می‌تواند ساده‌تر باشد.

پیچیدگی Operational را نمی‌خواهید

یک Application معمولاً:

Monitoring ساده‌تر،

Debugging ساده‌تر،

Deployment ساده‌تر،

و Transaction Management ساده‌تری دارد.

می‌خواهید آینده را باز نگه دارید

اگر Module Boundaryها درست طراحی شوند، بعدها می‌توان بخشی را که واقعاً نیاز دارد از Monolith خارج کرد.

Modular Monolith می‌تواند تصمیم Architecture آینده را به تعویق بیندازد بدون اینکه Code امروز بی‌ساختار شود.

چه زمانی Microservices منطقی‌تر می‌شود؟

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

مثلاً:

Scale مستقل

Catalog میلیون‌ها Read دارد ولی Back-office Traffic کمی دارد.

Scale کردن تمام سیستم برای Catalog هزینه غیرضروری ایجاد می‌کند.

Release مستقل

Payment Team باید بتواند بدون منتظرماندن برای Release کل Application نسخه خودش را منتشر کند.

تیم‌های متعدد

چند Team مستقل روی Business Capabilityهای مشخص کار می‌کنند.

AWS در Service-per-Team Pattern توضیح می‌دهد که Service Ownership می‌تواند به Teamها اجازه دهد مستقل توسعه، تست، Deploy و Scale کنند.

Fault Isolation

خرابی Recommendation نباید Checkout را از کار بیندازد.

نیازهای فنی واقعاً متفاوت

مثلاً Search نیاز به Infrastructure متفاوتی از Transaction Processing دارد.

Domain Boundaryهای بالغ

تیم به‌اندازه کافی Business Domain را می‌شناسد که بتواند Boundaryهای نسبتاً پایدار تعریف کند.

اگر این نیازها وجود ندارند، ممکن است Microservices تنها شکل جدیدی از پیچیدگی باشد.

تیم شما بخشی از Architecture است

Architecture فقط Diagram نرم‌افزار نیست.

ساختار Team هم مهم است.

اگر یک Service پنج Owner دارد، مسئولیت آن مبهم می‌شود.

اگر برای تغییر یک Feature سه Team باید هماهنگ شوند، استقلال Service روی Diagram کمک زیادی نمی‌کند.

AWS در Service-per-Team Pattern پیشنهاد می‌کند هر Microservice مالک مشخص داشته باشد تا Team بتواند Lifecycle آن را از Development تا Deployment مدیریت کند.

Microsoft نیز Microservices را مناسب Teamهای کوچک و مستقلی می‌داند که یک Service را End-to-End مدیریت می‌کنند.

پس سؤال Architecture این هم هست:

چه کسی قرار است مالک این Boundary باشد؟

Data یکی از سخت‌ترین مرزهاست

شکستن Code نسبتاً ساده است.

شکستن Data معمولاً سخت‌تر است.

در Monolith ممکن است یک Transaction ساده روی چند Table انجام شود.

وقتی این Tableها بین چند Service تقسیم شوند، دیگر یک ACID Transaction ساده روی تمام آن‌ها نداریم.

Microsoft در راهنمای Data Sovereignty توضیح می‌دهد که Microserviceها باید Data خود را مالک باشند، اما همین استقلال باعث می‌شود Data Access و Transactionهای بین چند Context پیچیده‌تر از Database مشترک Monolith شوند.

اینجاست که مفاهیمی مثل:

• Eventual Consistency
• Saga
• Messaging
• Outbox
• و Idempotency

وارد Architecture می‌شوند.

اگر Business Requirement شما به Transactionهای زیادی بین چند Module وابسته است، قبل از جداکردن آن‌ها باید هزینه این Complexity را در نظر بگیرید.

Modularity می‌تواند قبل از Microservices بیاید

این یکی از مهم‌ترین راهبردهای عملی است.

لازم نیست انتخاب ما از روز اول فقط این دو باشد:

Monolith بی‌ساختار

یا:

Microservices کامل.

می‌توان ابتدا Domain Boundaryها را داخل Application روشن کرد.

مثلاً:

Orders

فقط از Public Contract مربوط به:

Inventory

استفاده کند.

هر Module Model خودش را داشته باشد.

Dependencyها جهت مشخص داشته باشند.

Test Boundaryها نوشته شوند.

Business Logic داخل Module مالک خودش بماند.

بعد اگر روزی Inventory واقعاً نیاز به:

Independent Scaling

Independent Deployment

یا Team Ownership مستقل

داشت، Extraction بسیار منطقی‌تر خواهد بود.

AWS Well-Architected حتی توصیه می‌کند اگر از Monolith شروع می‌کنید، آن را Modular نگه دارید تا با رشد Product امکان حرکت به SOA یا Microservices وجود داشته باشد.

یعنی:

لازم نیست امروز هزینه معماری فردا را کامل پرداخت کنید؛ اما بهتر است راه فردا را هم نبندید.

برای سیستم Legacy لازم نیست همه‌چیز را یک‌باره بازنویسی کنید

فرض کنید یک Monolith ده‌ساله دارید.

نباید اولین تصمیم این باشد:

از شنبه همه را Microservice می‌کنیم.

Rewrite کامل Risk بسیار بالایی دارد.

AWS برای Modernization سیستم‌های موجود الگوهایی مثل Strangler Fig و Branch by Abstraction را پیشنهاد می‌کند.

در Strangler Fig یک قابلیت به‌تدریج از Monolith خارج می‌شود و سیستم جدید و قدیمی برای مدتی کنار هم کار می‌کنند.

Branch by Abstraction هم برای بخش‌هایی مفید است که عمیق‌تر داخل Legacy Application قرار گرفته‌اند و نمی‌توان به‌راحتی Traffic آن‌ها را از بیرون Redirect کرد.

Modernization خوب معمولاً:

مرحله‌ای است، نه انفجاری.

اولین Module را از درد واقعی انتخاب کنید

اگر قرار است Monolith را Modular کنیم، لازم نیست سخت‌ترین بخش سیستم را اول انتخاب کنیم.

بهتر است Boundaryای پیدا کنیم که:

مسئولیت نسبتاً مشخصی دارد.

Dependencyهای محدودتری دارد.

Business Value مشخصی دارد.

و تغییرش Risk قابل‌کنترلی دارد.

مثلاً Notification ممکن است Candidate بهتری از Ordering Core باشد.

بعد تیم می‌تواند روی همان بخش:

Boundary Design

Contract

Data Ownership

Testing

Deployment

و Observability

را یاد بگیرد.

Google در Tutorial تازه خود درباره Modularization نیز فرایند Production را معمولاً Incremental می‌داند: یک Component جدا می‌شود، دوباره با سیستم یکپارچه می‌شود و پس از اطمینان از عملکرد درست، سراغ Component بعدی می‌رویم.

از Dependency Direction مراقبت کنید

داشتن Module کافی نیست.

Dependencyها هم باید قابل‌کنترل باشند.

اگر:

Orders → Inventory

Inventory → Orders

Payments → Orders

Orders → Payments

و همه به Common Library عظیمی وابسته باشند، به‌تدریج Circular Dependency ساخته می‌شود.

یکی از اهداف Boundary خوب این است که Dependency Direction روشن باشد.

برای بعضی ارتباط‌ها Direct Call مناسب است.

برای بعضی Interface.

برای بعضی Event.

اصل مهم‌تر از Technology این است:

Module نباید برای انجام کار خودش مجبور باشد Implementation داخلی Module دیگر را بشناسد.

Common Library می‌تواند به Monolith مخفی تبدیل شود

گاهی تیم Microservices ساخته است.

اما همه Serviceها به Package بزرگی به نام:

Company.Common

وابسته‌اند.

داخل آن:

Domain Model

Validation

Database Entity

Authentication Logic

Utility

Business Rules

همه وجود دارد.

حالا هر تغییر در Common Package نیازمند Update چند Service است.

از نظر Deployment چند Service داریم.

از نظر Coupling هنوز Monolith داریم.

Microsoft هم هشدار می‌دهد Shared Libraryها بین Microserviceها می‌توانند Tight Coupling ایجاد کنند و تغییر را گسترده و پرریسک کنند.

Reuse همیشه هدف نهایی نیست.

گاهی کمی Duplication ارزان‌تر از Dependency دائمی است.

Modularity باید قابل تست باشد

اگر ادعا می‌کنیم Moduleها مستقل‌اند، باید بتوانیم Boundary آن‌ها را تست کنیم.

مثلاً:

آیا Orders می‌تواند بدون دسترسی مستقیم به Tableهای Inventory کار کند؟

آیا Contract بین Moduleها مشخص است؟

آیا تغییر Internal Model یک Module بقیه را می‌شکند؟

آیا Circular Dependency ایجاد شده؟

آیا Architecture Ruleها در CI قابل بررسی‌اند؟

Architecture نباید فقط سندی باشد که روز اول پروژه نوشته شده است.

بخشی از آن باید در Code و Test قابل Enforcement باشد.

معماری‌ای که فقط روی Diagram وجود دارد، با اولین Deadline جدی تغییر می‌کند.

چه زمانی معماری ماژولار ارزش ندارد؟

تقریباً هر Software غیرساده‌ای از Separation of Concerns سود می‌برد.

اما Over-engineering هم واقعی است.

برای Prototype کوتاه‌عمر یا Application بسیار کوچک شاید تعریف ده‌ها Boundary، Event و Abstraction هزینه‌ای ایجاد کند که هیچ‌وقت برنمی‌گردد.

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

Microsoft تأکید می‌کند Single Application در بسیاری از شرایط ساده‌تر است و Microservices فقط زمانی ارزش هزینه اضافه را دارند که واقعاً Business Requirement آن استقلال را ایجاد کند.

پس میزان Modularity هم باید با اندازه و آینده Product متناسب باشد.

Monolith، Modular Monolith یا Microservices؟

یک مقایسه ساده می‌تواند کمک کند:

این جدول قانون قطعی نیست.

اما یک نکته را روشن می‌کند:

Microservices مرحله «بهتر» Modular Monolith نیست.

Architecture متفاوتی با Trade-off متفاوت است.

یک Framework عملی برای انتخاب معماری

قبل از انتخاب Architecture این سؤال‌ها را بپرسید:

بهترین معماری، پیچیده‌ترین معماری نیست

یک Diagram با ۴۰ Service ممکن است بسیار حرفه‌ای به نظر برسد.

اما Architecture برای Diagram ساخته نمی‌شود.

برای تغییرکردن نرم‌افزار ساخته می‌شود.

اگر هر Feature کوچک هنوز نیازمند تغییر هشت Service باشد، Microservices مسئله را حل نکرده‌اند.

اگر Modular Monolith اجازه می‌دهد یک Team کوچک با سرعت، کیفیت و هزینه مناسب Product را توسعه دهد، تبدیل آن به Distributed System فقط به این دلیل که «مدرن‌تر» به نظر می‌رسد ارزش خاصی ندارد.

و اگر Monolith باعث شده چند Team نتوانند مستقل Release کنند، بخش‌های مختلف Scaling بسیار متفاوتی داشته باشند و هر تغییر خطر کل سیستم را بالا ببرد، آن‌وقت جداسازی می‌تواند ارزش واقعی ایجاد کند.

هدف معماری ماژولار این نیست که همه‌چیز را خرد کنیم.

هدف این است که تغییر را محلی کنیم.

وقتی Order تغییر می‌کند، تا جای ممکن فقط Order تغییر کند.

وقتی Payment مشکل دارد، کل Product از کار نیفتد.

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

و وقتی Product رشد می‌کند، Architecture بتواند همراه آن رشد کند.

معماری خوب قرار نیست آینده را دقیق پیش‌بینی کند.

قرار است کاری کند وقتی آینده رسید، تغییر سیستم هنوز ممکن باشد.

→بازگشت به مقالات