معماری رویدادمحور
الگو‌های معماری رویداد محور

بنا به دلایلی همچون scalability، flexibility و coupling کم، ممکن است یک تیم توسعه‌ی نرم‌افزار تصمیم بگیرد سیستم خود را به نحوی طراحی و پیاده‌سازی کند که بین اجزای خود از ارتباط و پردازش رویداد محور استفاده کند. به همین منظور تیم توسعه‌ی مذکور باید به استفاده از الگو‌های معماری رویداد محور روی بیاورد. در این قسمت برخی از این الگو‌ها را نام برده و به اختصار توضیح می‌دهیم.
Event Sourcing: با استفاده از این الگو، حالت و state کنونی اپلیکیشن را می‌توان از ثبت و بازپخش رویداد‌ها به دست‌ آورد. در واقع state کنونی اپلیکیشن از record کردن رویداد‌ها نشات می‌گیرد. به جای اینکه در هر نقطه از زمان state کنونی اپلیکیشن را ذخیره کنیم، هر تغییر در state را یک رویداد می‌انگاریم و آن را در گزارشی از رویداد‌ها ذخیره می‌کنیم. این رویکرد طراحی معماری باعث می‌شود تا قابلیت حسابرسی ردپای تغییرات سیستم را به راحتی داشته باشیم و در هر زمانی که بخواهیم state کنونی اپلیکیشن را بازسازی کنیم.
Command Query Responsibility Segregation: با استفاده از این الگوی معماری، وظایف read و write در سیستم را به مدل‌های جدایی می‌سپاریم به گونه‌ای که با مدل command، عملیات و دستورات write را اجرا می‌کنیم که هریک state کنونی سیستم را تغییر می‌دهند. در حالی که با پیاده سازی مدل query و استفاده از آن، دستورات read را در سیستم اجرا می‌کنیم و داده‌ها را بازیابی می‌کنیم. از آن‌جایی که با این کار می‌توانیم دستورات read و write را به صورت مجزا بهینه سازی و optimize کنیم، در نهایت scalability سیستم را بالا می‌بریم.
Publish-Subscribe Pattern: نام دیگر این الگو ، observer pattern است. در این الگو دو نوع component سیستم به نام‌های publisher و subscriber داریم. Subscriber ها نیازمند انواع خاصی از رویداد‌ها از طرف publisher ها هستند و publisher ها بدون اینکه به صورت مستقیم در رابطه با کلیت subscriber ها چیزی بدانند، برای آن‌ها رویداد ارسال می‌کنند. با استفاده از این الگو flexibility سیستم را افزایش داده و در نهایت coupling را کاهش می‌دهیم.
Message Queue: با استفاده از این الگوی معماری برای فراهم سازی زیرساخت ارتباط بین component ها و اجزای مختلف سیستم، یک broker و واسط پیام‌ها تعبیه و پیاده سازی می‌کنیم. با پیاده سازی یک broker پیام، قابلیت ارسال پیام به صورت asynchronous را برای component ها فراهم می‌کنیم و در نهایت می‌توانیم از صحت پیام ارسالی اطمینان خوبی حاصل کرده و fault tolerance خوبی خواهیم داشت. این واسط پیام یک صف از پیام‌ها دارند و component هایی که وظیفه‌ی publish کردن را دارند، پیام خود را در این صف ارسال می‌کنند و در عین حال بقیه‌ی component ها می‌توانند از روی این صف، پیام‌ها را به هنگام آماده شدن دریافت کنند.
Choreography and Orchestration: این الگو‌های معماری، علاوه بر اینکه چگونگی همکاری اجزای مختلف یک سیستم رویداد محور را  تعیین می‌کنند، همچنین وظیفه‌ی هماهنگی عملکرد اجزا و component های مذکور را نیز بر عهده دارند. در Choreography، هرکدام از component ها به صورت مستقلی به رویدادها واکنش نشان می‌دهند و رفتار و state کلی سیستم از ترکیب این فعل و انفعالات component ها شکل می‌گیرد. در Orchestration یک component مرکزی پیاده سازی شده که وظیفه هماهنگی اقدامات و action های سایر component ها را برعهده دارد و به آن‌ها جهت می‌دهد.
Event-Driven Messaging: با استفاده از این نوع الگو‌ها، یک سری پیام‌ها به صورت رویداد‌هایی بین component های سیستم، به منظور شروع یک سری اقدامات و action ها و القای یک سری اطلاعات، رد و بدل می‌شوند. مثال‌هایی از این نوع الگو‌ها : request-reply , event notification , message routing , …
همانگونه که بیان شد، می‌توانیم پس از بررسی‌های لازم با استفاده از این الگو‌های معماری رویداد محور برای طراحی سیستم‌های بزرگ و پیچیده، flexibility و scalability را افزایش دهیم. این الگو‌های رویداد محور باعث می‌شوند سیستم توانایی پردازش حجم عظیمی از رویداد‌ها را داشته باشد و به تغییرات component های خود واکنش درستی نشان دهد. همچنین فرایند یکپارچه‌سازی سیستم مورد نظر را با سایر سیستم‌ها آسانتر میکنند. در کل با استفاده از این الگو‌ها می‌توان سیستم‌هایی بهینه طبق استاندارد‌های روز توسعه‌ی نرم‌افزار طراحی و پیاده سازی کرد.