در حوزه معماری نرم‌افزار مدرن، برنامه‌های سنتی CRUD (ایجاد، خواندن، به‌روزرسانی، حذف) اغلب هنگام برخورد با منطق کسب‌وکار پیچیده و الزامات حسابرسی سخت‌گیرانه به بن‌بست می‌خورند. اینجاست که Event Sourcing نه تنها به عنوان یک الگو، بلکه به عنوان یک تغییر پارادایم بنیادین وارد عمل می‌شود. با جداسازی وضعیت فعلی سیستم از تاریخچه تغییرات، توسعه‌دهندگان می‌توانند سیستم‌هایی شفاف‌تر، انعطاف‌پذیرتر و مقاوم‌تر بسازند.
Event Sourcing چیست؟
در هسته اصلی، Event Sourcing یک الگوی معماری است که در آن وضعیت یک برنامه مستقیماً ذخیره نمی‌شود، بلکه از یک دنباله از رویدادها استخراج می‌گردد. به جای ذخیره وضعیت فعلی یک شیء (مثلاً OrderStatus = Shipped)، شما واقعیت وقوع یک رویداد را ذخیره می‌کنید (مثلاً OrderShipped).
یک حساب بانکی را تصور کنید. در یک سیستم سنتی، ممکن است ستون موجودی را در یک رکورد پایگاه داده به‌روزرسانی کنید. در یک سیستم مبتنی بر Event Sourcing، شما دفتری از تمام واریزها و برداشت‌ها دارید. برای یافتن موجودی فعلی، کافی است این رویدادها را با هم جمع کنید. این رویکرد منطق برنامه شما را به یک لاگ فقط-افزایشی (append-only) غیرقابل تغییر تبدیل می‌کند و به طور پیش‌فرض یک رد کامل حسابرسی را فراهم می‌سازد.
چرا Event Sourcing را انتخاب کنیم؟
مزیت اصلی Event Sourcing، توانایی بازسازی وضعیت یک موجودیت در هر نقطه از زمان است. این ویژگی برای عیب‌یابی، حسابرسی و انطباق با مقررات بسیار ارزشمند است. علاوه بر این، این الگو به طور طبیعی با طراحی مبتنی بر دامنه (DDD) همسو است، زیرا رویدادها اغلب نمایانگر نقاط عطف مهم کسب‌وکار هستند.
با این حال، این روش بدون پیچیدگی نیست. پرس‌وجو از داده‌ها پیچیده‌تر می‌شود، زیرا انبار رویدادها برای عملیات نوشتن بهینه شده است، نه خواندن. به همین دلیل است که Event Sourcing اغلب با CQRS (جداسازی مسئولیت دستورات و پرس‌وجوها) همراه می‌شود. شما از انبار رویداد برای عملیات نوشتن و از یک پایگاه داده جداگانه بهینه‌شده برای خواندن (مانند یک انبار SQL یا NoSQL) برای پرس‌وجوها استفاده می‌کنید.
پیاده‌سازی Event Sourcing: یک مثال کد
بیایید یک پیاده‌سازی ساده‌شده در جاوا را بررسی کنیم تا نشان دهیم چگونه وضعیت از رویدادها استخراج می‌شود. ما یک ریشه تجمیع (aggregate root) ساده ایجاد می‌کنیم که یک سفارش را مدیریت می‌کند.
public class Order {
private String orderId;
private OrderStatus status;
private List<ObjectEvent> events = new ArrayList<>();
// Constructor
public Order(String orderId) {
this.orderId = orderId;
this.status = OrderStatus.CREATED;
// Record the initial event
applyEvent(new OrderCreatedEvent(orderId));
}
// Command handler
public void ship() {
if (this.status != OrderStatus.PACKED) {
throw new IllegalStateException("Order must be packed before shipping");
}
applyEvent(new OrderShippedEvent(orderId, Instant.now()));
}
// Apply an event to the current state
private void applyEvent(ObjectEvent event) {
events.add(event);
event.apply(this);
}
// Rebuild state from events (used when loading from Event Store)
public void replay(List<ObjectEvent> historicalEvents) {
this.events = new ArrayList<>();
for (ObjectEvent event : historicalEvents) {
applyEvent(event);
}
}
}
// Interface for all events
interface ObjectEvent {
void apply(Order order);
}
// Example Event
class OrderShippedEvent implements ObjectEvent {
private String orderId;
private Instant shippedAt;
public OrderShippedEvent(String orderId, Instant shippedAt) {
this.orderId = orderId;
this.shippedAt = shippedAt;
}
@Override
public void apply(Order order) {
order.status = OrderStatus.SHIPPED;
System.out.println("Order " + orderId + " shipped at " + shippedAt);
}
}در این مثال، کلاس Order تاریخچه خود را ذخیره نمی‌کند. آن فقط وضعیت فعلی را نگه می‌دارد. زمانی که نیاز داریم سفارش را از حافظه بارگذاری کنیم، لیست تاریخی رویدادها را به روش replay ارسال می‌کنیم که به شیء اجازه می‌دهد خود را به دقت بازسازی کند.
چالش‌ها و بهترین شیوه‌ها
اگرچه قدرتمند است، Event Sourcing چالش‌هایی را به همراه دارد. مدیریت نسخه‌بندی حیاتی است؛ اگر طرح رویداد شما تغییر کند، باید سازگاری با نسخه‌های قبلی را مدیریت کنید. علاوه بر این، اگر به طور مکرر هزاران رویداد را بازپخش (replay) کنید، عملکرد ممکن است کاهش یابد. برای کاهش این مشکل، توسعه‌دهندگان اغلب اسنپ‌شات‌ها (snapshots) را پیاده‌سازی می‌کنند—یعنی وضعیت تجمیع را به طور دوره‌ای ذخیره می‌کنند تا از بازپخش رویدادهای قدیمی‌تر صرف‌نظر شود.
نتیجه‌گیری
Event Sourcing یک ابزار قدرتمند برای حوزه‌های خاص مسئله است، به ویژه آن‌هایی که به یکپارچگی بالا، تاریخچه پیچیده و انعطاف‌پذیری در گزارش‌دهی نیاز دارند. اگرچه این روش بر روی فرآیند توسعه بار اضافی تحمیل می‌کند، اما مزایای بلندمدت داشتن یک تاریخچه کامل و غیرقابل تغییر از دامنه کسب‌وکار شما، اغلب بر هزینه‌ها می‌چربد. با درک و به کارگیری این الگو، معماران می‌توانند سیستم‌هایی بسازند که نه تنها کاربردی، بلکه عمیقاً بینش‌بخش باشند.