ארכוויז מס' 1 – כיצד להגיב מהר לדרישות חדשות באפליקציה?
בעיה אמיתית אצל לקוח – איך לתכנן את מערכת כך שתאפשר להגיב מהר לדרישות ושינויים?
אוקיי, רגע לפני שרצים לפתח, בואו ננסה להבין מה הם הגורמים המרכזיים לבעיה והאם שכבה נוספת היא התשובה?
הבעיות
-
אין הפרדה טובה בין הרכיבים השונים - כל נגיעה בקוד גוררת תגובת שרשרת מה שמצריך מעבר לאורך ולרוחב המערכת לצורך
עדכונים ותיקונים ולכן כל שינוי מחייב תהליך בדיקות מקיף.
-
יקר להעלות גרסה חדשה לסביבת הייצור - אווצ'!!! תהליך ארוך, מייגע ויקר.
-
תדמית שלילית לצוות הפרויקט - חוסר שביעות רצון של לקוחות המערכת העסקיים.
אז מה עושים?
נשארים במצב הקיים - לקבל את הכאב כסגנון חיים [מעניין אם משתמשי המערכת יקבלו את זה?]
עדכון הארכיטקטורה ועיצוב המערכת
-
הנדסת תוכנה - ע"י design נכון, ניתן ליישם מודל בו קיימת הפרדה טובה בין שכבות ורכיבי המערכת כך ששינוי/עדכון לא גורר שינויים
רוחביים -
Coupling & Cohesion. שמרנו על סביבה פשוטה ללא תקורות נוספות כמו במקרה של הפרדת לשירותים
-
הפרדת שכבת הלוגיקה העסקית ע"י שכבת שירותים - מה הרווחנו?
לא צריך לגעת בסביבת הייצור כולה אלא רק בשירות אותו רוצים לעדכן. ע"י שמירה על מס' כללים בסיסיים הקשורים לניהול
גרסאות שירותים, אנו יכולים לצפות למעט מאוד נק' חיכוך שעלולות לגרור שינויים גורפים במערכת. נשמע טוב לא? אז זהו, שלא בטוח. מה עם תקורת ניהול השירותים, הוספת שרתים לחווה, ניהולם, ניהול תצורה, גרסאות מקבילות? וזה עוד לפני שהתחלנו לדבר על ביצועים. הוספנו תקשורת החוצה את גבולות ה- Process, מה עם latency? מה אבטחת מידע?
-
הפרדת החוקים העסקיים מן הקוד ע"י כלי BRE (Business Rule Engine) - כמובן שצריך לשקול את הפתרון ולוודא כדאיות ע"י בחינה של עלות מול תועלת.
כאשר מדובר במעט חוקים או מעט שינויים לאורך זמן, כנראה שלא שווה להשקיע במוצר וניתן להסתפק בפתרון פשוט מבוסס פיתוח עצמי.
לסיכום
לפני שרצים לבצע שינויים מרחיקי לכת חייבים לבצע תהליך של בחינת מצב ע"פ התסריטים העיקריים שמניעים את התהליך.
לאחר מיפוי התסריטים והצרכים ניתן לבצע ניתוח חלופות (design, Service layer, Rules Engine וכו') אמיתי ורציני. רק כך נוכל לבחור בפתרון המיטבי ולהצדיק
את העלויות.
קישורים רלוונטיים
1. Coupling & Cohesion
2. Business Layer Scenarios Frame
3. Service Layer Scenarios Frame
4. WF Rules Engine
5. Business Rules Engine