לוגיקה עסקית
בהנדסת תוכנה, ובפרט במערכות enterprise, לוגיקה עסקית (באנגלית: business logic) היא חלק ממערכת תוכנה שתפקידו לממש את הכללים העסקיים מ"העולם האמיתי". כללים אלו קובעים כיצד נתונים יכולים: להווצר, להשתנות, להיות מוצגים, ומאוחסנים. לרוב, המושג מתאר את החלק בתוכנה אשר מכיל את האלגוריתמים הפונקציונליים שמטפלים בהעברת מידע בין בסיס נתונים לממשק משתמש.
נהוג להבחין בין הלוגיקה העסקית לבין יתר חלקי התוכנה שיכולים להוות את התשתיות, או שהם אחראים על פרטים כגון ניהול בסיס נתונים, הצגת ממשק משתמש, והחיבור הכללי בין חלקי המערכת השונים.
תפקידים והרכב
תפקידי הלוגיקה העסקית:
- ממדלת אובייקטים עסקיים מהחיים האמיתיים (כדוגמת חשבונות, הלוואות, מסלולים, מלאי וכדומה).
- קובעת את טיב האינטראקציה בין אובייקטים עסקיים.
- מכתיבה את המסלולים והשיטות שלפיהם ניגשים לאובייקטים העסקיים ומעדכנים אותם.
לוגיקה עסקית מורכבת מ:
- כללים עסקיים (business rules) אשר מבטאים את המדיניות העסקית (כדוגמת ערוצים, מקומות, לוגיסטיקה, מחירים, מוצרים וכדומה).
- שלבי עבודה (workflow) המהווים סדרת משימות של העברת מסמכים או נתונים בין משתתף אחד (בן אדם או מערכת תוכנה) לשני.
דוגמה
בתור דוגמה, נחשוב על אתר אינטרנט למסחר אלקטרוני המאפשר למשתמשים להוסיף פריטים ל"עגלת קניות", להזין כתובת למשלוח ולספק מידע עבור אמצעי התשלום. הלוגיקה העסקית של אתר אינטרנט כזה עשויה לכלול את שלבי העבודה הבאים:
- סדר האירועים שמתרחשים בזמן סיום ההזמנה: לדוגמה, טופס הנפרש על פני מספר דפי אינטרנט, אשר תחילה מבקש להזין את הכתובת למשלוח ולאחר מכן את הכתובת לחיוב. הדף הבא יבקש להזין את פרטי אמצעי התשלום, והדף האחרון יציג ברכה על השלמה מוצלחת של הזמנה.
האתר גם יכלול כללים עסקיים כגון:
- הוספת אותו פריט יותר מפעם אחת מדף התיאור של המוצר, מגדילה את הכמות של אותו מוצר בעגלת הקניות.
- פורמטים ספציפיים ומחייבים עבור הכתובת למשלוח, כתובת דואר אלקטרוני ופרטי כרטיס אשראי שהמשתמש מזין.
- פרוטוקול תקשורת ספציפי לצורך דיבור עם מערכת החיוב של חברת האשראי.
התוכנה שמרכיבה את אתר האינטרנט תכיל גם רכיבים אחרים שאינם נחשבים לחלק מהלוגיקה העסקית או הכללים העסקיים:
- תוכן שאינו קשור ישירות לנתונים העסקיים, כדוגמת ה-HTML וה-CSS שמגדירים את התצוגה, המראה, הצבעים, תמונת הרקע והאלמנטים המבניים שמסייעים לנווט בין דפי האתר.
- קוד העוסק בטיפול הכללי בחריגות (לדוגמה: מה מוצג בעת קבלת שגיאת HTTP עם קוד 500).
- קוד העוסק באתחול, אשר רץ כאשר השרת מאתחל את האתר ומכין את המערכת לפעולה.
- מערכת ניטור (monitoring) שתפקידה לוודא שכל חלקי האתר פועלים כשורה (לדוגמה: ווידוא שמערכת החיוב זמינה).
- קוד כללי ליצירת חיבורי רשת, אחסון אובייקטים בבסיס הנתונים, קריאה של קלט מהמשתמש דרך בקשות HTTP POST, וכדומה.
לוגיקה עסקית וארכיטקטורה רב-שכבתית
הלוגיקה העסקית יכולה להיות בכל אחד מחלקי התוכנה. לדוגמה, בהינתן פורמט מסוים של כתובת מגורים, ניתן ליצור בבסיס הנתונים טבלה עם עמודות המתאימות לשדות המפורטים על ידי הלוגיקה העסקית, ולהוסיף בדיקות תקינות על מנת לוודא שלא מוכנסים נתונים בלתי חוקיים.
הלוגיקה העסקית עשויה להשתנות לעיתים קרובות. לדוגמה, קבוצת הפורמטים המגדירים כתובות חוקיות למשלוח יכולה להשתנות כאשר סוחר באינטרנט מתחיל לשלוח מוצרים למדינות חדשות. מסיבה זו, בדרך כלל רצוי להפוך את הקוד שמממש את הלוגיקה העסקית למבודד יחסית, או בעל צימוד רפוי (loosely coupled). בזכות תכונה זו, סביר ששינויים בלוגיקה העסקית יצריכו פחות שינויים בקוד, ורק באחד מחלקי מערכת התוכנה. תוכנה הממומשת עם צימוד חזק (strongly coupled), מעלה גם את הסיכון שהמתכנת יבצע רק חלק מהשינויים הנדרשים בקוד, ויפספס חלקים אחרים מהמערכת, מה שיוביל לפעילות לא תקינה של התוכנה (באגים).
ארכיטקטורה רב-שכבתית הופכת את הסרת הצימוד (decoupling) לרשמי על ידי יצירה של שכבת לוגיקה עסקית. שכבה זו נפרדת משכבות התוכנה האחרות, כגון שכבת הגישה לנתונים (data access layer) או שכבת השירותים (service layer). כל שכבה "יודעת" רק את המינימום ההכרחי לגבי הקוד בשכבות האחרות - רק את מה שנדרש לצורך השלמת המשימות הנדרשות. לדוגמה, בפרדיגמת ה-model-view-controller, שכבת הגישה לנתונים או בסיס הנתונים (ה-model), ושכבת ממשק המשתמש (ה-view), ניתנות למימוש כך שיהיו פאסיביות ככל הניתן, כך שכל הלוגיקה העסקית תתרכז ב-controller.
בדוגמה של אתר הקניות ברשת שניתנה למעלה, ה-controller יקבע את סדר דפי האינטרנט בתהליך ביצוע ההזמנה, וכמו כן הוא אחראי על ווידוא התקינות (ולידציה) של כתובת הדואר האלקטרוני, הכתובת למשלוח והמידע אודות אמצעי התשלום, במטרה לספק את כל הכללים העסקיים (במקום להשאיר את העבודה הזאת לבסיס הנתונים עצמו, או לקוד אחר "נמוך" יותר שתפקידו לתקשר עם בסיס הנתונים).
קיימות גם פרדיגמות אלטרנטיביות. לדוגמה, במקרה של ישויות עסקיות פשוטות יחסית, view ו-controller גנריים יכולים לגשת לאובייקטים של בסיס הנתונים, שהם עצמם מכילים את כל הלוגיקה העסקית הרלוונטית לגבי פורמטים תקינים ואילו שינויים אפשריים (ידוע בשם database model).