כשמודל הנתונים כבר לא מתאים, זה הזמן להכיר את Event Sourcing ו-CQRS

כך מציע לידן חיפי, ראש צוות פיתוח ב-Wix Engineering, שמסביר בהרצאה איך בעזרת כלים אלה ניתן לבנות ארכיטקטורה יעילה וגמישה הרבה יותר

מאת לידן חיפי, ראש צוות פיתוח ב-Wix Engineering

כל ארכיטקט תוכנה מכיר זאת: אנחנו מתאימים מודל נתונים לאפליקציה מסוימת ומתעקשים להמשיך לעבוד איתו, למרות שהוא כבר לא מתאים לצורכי האפליקציה שמשתנים עם הזמן. זו דוגמה למה שמכונה Accidental Complexity, ויש לכך כמה פתרונות יעילים.

לידן והצוות שלו התחילו לבנות ארכיטקטורת נתונים פשוטה לאפליקציית ה-Wix Invoices, אך לאחר זמן קצר הבינו שהיא אינה עונה על הצרכים המשתנים של האפליקציה, משום שכל שינוי שעשה המשתמש “דרס” את הנתונים הקיימים במערכת, וכך נוצר מצב של אבדן מידע באופן מתוכנן וכחלק מהעיצוב של המערכת.

הארכיטקטורה הזו בעייתי במיוחד כשמדובר באפליקציות פיננסיות (למשל בתחומי הרפואה או הביטוח), ויש לכך שלוש סיבות בולטות:

  • עמידה בתקינות: מדובר בגופים שכפופים לרגולטורים, והאפליקציה חייבת לתמוך ולעמוד בתנאי הרגולציה כדי לא לחשוף אותם לתביעות משפטיות
  • Scalability: האפליקציה צריכה לעבוד ביעילות גם כשמדובר בכמויות גדולות מאוד של משתמשים
  • גמישות: האפליקציה צריכה לאפשר הוספה פשוטה של פיצ’רים כדי לתמוך במודלים עסקיים שמשתנים עם הזמן

Event Sourcing

בהרצאתו מספר לידן על שלושת האתגרים הללו ועל ארכיטקטורת הנתונים שתתמוך בהם, ונותן דוגמה מעולם הצעות החוק בישראל שממחישה את כל הסיפור. הצעת חוק בישראל עוברת כמה גרסאות עד העלאתה להצבעה. כל תיקון נעשה על סמך תיקונים קודמים, ולעולם לא על ההצעה המקורית. מדוע? כדי לראות את התהליך שעומד מאחורי התיקונים והשינויים על מנת להבין את הסיבות להם. בדיוק כך ביקשו לידן וצוות ה-CRM להתייחס לשינויים באפליקציה שלהם, ועברו לעבוד בתבנית שנקראת Event sourcing.

בהרצאתו מפרט לידן את השיטה והיתרונות הברורים לשמירה של רצף ה-events שהביאו ל-state, במקום שמירה של ה-state בלבד, ובראשם היכולת לשחזר אותו באמצעות ה-events. (עוד על Event sourcing ניתן לקרוא בכתבה של לידן כאן). אבל כדי לעבוד בשיטה הזאת יש לבטא כל פעולה במערכת בשפה של הדומיין, על מנת שכלל הצדדים יבינו אותה –הדומיין, המוצר והפיתוח. שפה זו, מסביר לידן, כוללת שני מבנים עיקריים: event ו-command.

התוצאה היא שמי שקורא את רצף ה-events מבין בדיוק מה המשתמש עשה במערכת, היות שאף פעם לא מתבצע שכתוב של היסטוריית ה-events. ובמלים אחרות, עכשיו האפליקציה עומדת ברגולציה, ולא פחות חשוב מכך – אין כלל איבוד של מידע. בנוסף, כעת כל המערכת היא לפי שפת הדומיין, ולא לפי השפה שהטכנולוגיה מאלצת אותנו להשתמש בה.

CQRS

בחלקה השני של הרצאתו, מדבר לידן על חוסר הסימטריה החד שבין קריאות וכתיבות לבסיס הנתונים, כפי שמתבצע במערכות כיום. לרוב, הוא מסביר, כשכותבים מערכת אנו נוטים לחבר בין המודל של הקריאה לבין המודל של הכתיבה, אבל לעתים קרובות שני המודלים הללו שונים לחלוטין. זה יוצר שורה של בעיות שימוש ב-database, שהפתרון להן הוא: Command, query, responsibility and segregation – CQRS.

ברגע שאנו מפרידים את הקריאות מהכתיבות אנחנו יכולים להתייחס לכל אחת בצורה שונה. מה זה נותן לנו? התבנית הזאת מאפשרת לבנות נקודות מבט מעל ה-data, ופותחת בפני ארכיטקטים אפשרויות נוספות לניהול ולתחזוקת האפליקציה ביעילות.

בהרצאה לידן מפרט דוגמאות שונות לשימוש ב-CQRS ומדגיש נקודה חשובה – CQRS מאפשר למעשה לבצע אופטימיזציה, וכמו בכל אופטימיזציה יש להיזהר מלבצע אותה מראש. למשל, לא בכל פעם שיש בעיות scalability ה-CQRS יפתור את הבעיה, ולעתים זה אף עלול לייצר מורכבויות נוספות. אז מתי כן כדאי לשקול להשתמש בתבנית הזו? לידן מפרט שלושה מצבים: כשיש בעיות סקיילביליות, כשיש חוסר סימטריה מובהק בין הקריאות לכתיבות וכאשר אופן הקריאה של הנתונים שונה מהצורה שבה הם נכתבו, ונדרש עיבוד מאסיבי עד שהנתונים מגיעים למשתמש.

ומה Event sourcing ו-CQRS מעניקים למערכת מלבד Scalability והוספת פיצ’רים בקלות? לידן מפרט שלושה יתרונות נוספים:

  • Audit log שיכול לשמש כלי לניפוי שגיאות (debugging)
  • ניתוח של התנהגות המשתמשים
  • אפשרות לייצר כל מיני views שאפשר למחוק בכל רגע נתון ולייצר אותם מחדש

רגע לפני שאתם רצים לשכתב את הכל, חשוב לזכור שבאפליקציות גדולות ומורכבות השימוש בכלים הללו מעלה אתגרים נוספים שצריך להביא בחשבון. לידן נותן בהרצאתו כמה פתרונות אפשריים לבעיות מורכבות כגון:

  • איך לטפל בחוסר קונסיסטנטיות של ה-views?
  • איך עושים validation ל-commands?
  • איך מתמודדים עם כתיבה במקביל?

את הרצאתו מסיים לידן בטיפ חשוב: כשמתחילים לעבוד בשיטה הזאת כדאי להתחיל בקטן. לא כל entity במערכת שלנו צריך את ההיסטוריה ש-event sourcing מספק לנו. בסופו של דבר, event sourcing ו-CQRS אינם פתרונות קסם והבחירה בארכיטקטורה אחת על פני השנייה אינה בחירה בין משהו טוב לרע, אלא מעין trade off שתלוי בדרישות המוצר.

הכתבה בחסות Wix Engineering

Wix היא פלטפורמה לפיתוח Online Presence באינטרנט, עם למעלה מ-130 מיליון משתמשים ב-190 מדינות. אנחנו ב-Wix Engineering מפתחים אפליקציות ענן מהמתקדמות בעולם, מקדישים זמן להתפתחות מקצועית ולמידה ולוקחים גם את ההנאה שלנו באותה הרצינות. תרבות הפיתוח שלנו מבוססת על חדשנות, יצירתיות ועל הצורך והרצון להמשיך לאתגר את עצמנו ואת גבולות הטכנולוגיה. אנו משתמשים בטכנולוגיות המתקדמות ביותר (Scala, Node, React, and Angular), בפלטפורמות מבוססות ענן (Google, Amazon and Azure) ומיישמים מתודולוגיות כגון Continuous Delivery ו-TDD. ל-Wix, שני מרכזי פיתוח בישראל - בתל-אביב ובבאר-שבע. מוזמנים לעקוב אחרינו גם ב-Twitter וב-Facebook.

כתב אורח

אנחנו מארחים מפעם לפעם כותבים טכנולוגים אורחים, המפרסמים כתבות בתחומי התמחות שלהם. במידה ואתם מעוניינים לפרסם פוסט בשמכם, פנו אלינו באמצעות טופס יצירת קשר באתר.

הגב

2 תגובות על "כשמודל הנתונים כבר לא מתאים, זה הזמן להכיר את Event Sourcing ו-CQRS"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

* שימו לב: תגובות הכוללות מידע המפר את תנאי השימוש של Geektime, לרבות דברי הסתה, הוצאת דיבה וסגנון החורג מהטעם הטוב ו/או בניגוד לדין ימחקו. Geektime מחויבת לחופש הביטוי, אך לא פחות מכך לכללי דיון הולם, אתיקה, כבוד האדם והדין הישראלי.

סידור לפי:   חדש | ישן | הכי מדורגים
דוד
Guest

אחרי שהכרתי מקרוב את WIX למדתי עליהם 3 דברים:
1. הם טובים מאוד ב”גאוות יחידה”
2. הם בטוחים שהם בשיא הטכנולוגיה ועם הבטחון מגיע האוונגליזם (שמטרתו היא מוניטין איכותי וגיוס עובדים חדשים)
3. הם ממש לא בשיא הטכנולוגיה

אבנר
Guest

עוד אחד שניסה להתקבל ולא הצליח… בסדר, קורה. הכל טוב

wpDiscuz

תגיות לכתבה: