Separation of Concerns – אביב רונן

טעויות נפוצות ביישום ארכיטקטורה נקייה – וכיצד להימנע מהן

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

טעות #1: יצירת ממשקים מיותרים

הטעות הנפוצה הראשונה היא יצירת ממשקים (interfaces) לכל דבר, גם כשלא באמת צריך. זה בדרך כלל מגיע מהרצון ללכת "עד הסוף" עם עקרון היפוך התלות (Dependency Inversion) של הארכיטקטורה הנקייה. העיקרון אומר שהשכבות הפנימיות מגדירות ממשקים, והשכבות החיצוניות מממשות אותם, כדי שהקוד העסקי לא יהיה תלוי בפרטים הטכניים. אבל זה לא אומר שצריך להגדיר ממשק נפרד לכל מחלקה או שירות אם בפועל יש רק מימוש אחד.

לעיתים קרובות אני רואה צוותים שיוצרים ממשקים "ליתר ביטחון" – מתוך מחשבה שאולי בעתיד נצטרך עוד וריאציות, או סתם כי זה נראה להם "נקי" יותר. בפועל, זה עלול לסרבל את הקוד ולהכניס מורכבות מיותרת. פתאום, בשביל לעקוב אחרי מה שקורה, אתם צריכים לפתוח גם את קובץ ה־interface וגם את קובץ המימוש שלו, למרות שאין ביניהם שום הבדל מהותי.

לדוגמה, בפרויקט Node.js עם TypeScript, נתקלתי במקרים שבהם מגדירים ממשק UserRepository ואחריו מחלקה MongoUserRepository שמממשת אותו – למרות שאין שום מימוש אחר. הקוד נראה בערך כך:

interface UserRepository {
  findById(id: string): Promise<User | null>;
  save(user: User): Promise<void>;
}

class MongoUserRepository implements UserRepository {
  async findById(id: string): Promise<User | null> {
    // ... מממש חיפוש במסד נתונים MongoDB ...
  }
  async save(user: User): Promise<void> {
    // ... מממש שמירה במסד הנתונים ...
  }
}

יש כאן שני קבצים ושתי ישויות נפרדות בקוד, בשביל מה שבעצם הוא פעולה אחת פשוטה – אחזור ושמירת משתמשים. אם אין כרגע עוד מקור נתונים למשתמשים (למשל, אין גם PostgresUserRepository או InMemoryUserRepository), אז הממשק הזה לא משרת מטרה מיידית.
אגב, זאת טעות שאני עושה בעצמי הרבה פעמים.

איך להימנע מהטעות הזו? פשוט: לא להפוך הכל למופשט אם אין בכך צורך. אפשר להתחיל במחלקה קונקרטית (למשל מחלקת UserRepository ללא ממשק) ולהגדיר ממשק רק כשבאמת צריך אותו – למשל כשיש כמה מימושים, או כדי להקל על כתיבת בדיקות יחידה. אפשר תמיד להוסיף ממשק מאוחר יותר אם הפרויקט מתרחב, אבל קשה יותר להסיר מורכבות מיותרת אחרי שהיא נטמעה בקוד. כלל אצבע טוב הוא להימנע מ"Abstraction for the sake of abstraction" – אל תבצעו הפשטה רק כי "ככה עושים", אלא רק כשיש לה הצדקה מעשית. זה דורש תירגול וניסיון.

טעות #2: הפרדה קיצונית מדי

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

כשמפרידים כל דבר קטן באופן קיצוני, מאבדים לפעמים את התמונה הכוללת. ראיתי פרויקטים שבהם כל שכבה ארוזה כחבילה נפרדת (למשל, מודול נפרד ל"דומיין", מודול ל"מקרי שימוש", מודול ל"גישה לנתונים" וכן הלאה). התוצאה הייתה ששינוי אחד קטן דרש לעדכן כמה חבילות שונות ולהתמודד עם האינטגרציה המעודכנת ביניהן, במקום פשוט לשנות פונקציה במקום אחד.

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

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

טעות #3: מיקום שגוי של לוגיקה

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

כשלוגיקה עסקית מתערבבת בשכבה חיצונית, אנחנו מאבדים את ההפרדה שרצינו. קשה יותר לבדוק את זה בטסטים בבידוד (כי הם קשורים למסגרת חיצונית) וקשה לעשות בהם שימוש חוזר. דמיינו שיש לנו כלל עסקי חשוב שממומש רק בקוד של ה-API: אם מחר נרצה להשתמש בו גם במקום אחר (נניח בסקריפט רקע או בשירות נוסף), נצטרך לשכפל את הקוד או לחלץ אותו בדיעבד.

זה קטע קוד לדוגמה מroute ב-Express, שבו נעשתה טעות כזו:

// Express controller example (presentation layer)
app.post('/orders', async (req, res, next) => {
  try {
    const orderData = req.body;
    // בדיקת כלל עסקי בשכבת הקונטרולר - טעות!
    if (orderData.items.length === 0) {
      return res.status(400).json({ error: 'Order must include at least one item' });
    }
    const order = await OrderModel.create(orderData);  // שמירת ההזמנה ישירות דרך מודל הנתונים
    res.status(201).json(order);
  } catch (err) {
    next(err);
  }
});

בדוגמה הזו בדיקת התנאי "האם ההזמנה ריקה" מתבצעת ישירות ב-controller, ולא בשכבת הלוגיקה העסקית. המשמעות היא שאם נוסיף דרך נוספת ליצור הזמנות (נניח ממשק מנהל או שירות חיצוני), ייתכן שהכלל הזה לא ייאכף כי הוא לא נמצא במקום מרוכז אחד. בנוסף, הקוד שומר את ההזמנה ישירות באמצעות מודל מסד הנתונים (OrderModel), כך ששכבת הדומיין בכלל לא מעורבת בתהליך.

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

כדי לתקן מצב כזה, כדאי להעביר את הלוגיקה הזו פנימה. למשל, אפשר לממש את הכלל בדומיין עצמו – שהאובייקט Order לא יאפשר יצירה של הזמנה בלי פריטים, או להוסיף בדיקה בשכבת ה-Use Case (מקרה השימוש) לפני השמירה. כך, ה-controller יטפל רק בבקשת ה-HTTP ויעביר את הנתונים לשכבת הלוגיקה שתבצע את כל הבדיקות והפעולות העסקיות. הגישה הזו מבטיחה שכללי העסק מתקיימים תמיד, לא משנה מאיפה מתקבלת הקריאה.

טעות #4: שכבות סרק

בהמשך ישיר להפרדה מוגזמת, יש מקרים שבהם מממשים שכבה שלמה שלא עושה כמעט כלום – היא רק מקבלת קריאה ומעבירה אותה לשכבה הבאה. אלה "שכבות סרק" קלאסיות.

לפעמים זה נובע מהרצון לעקוב אחרי התבנית הנקייה אחד לאחד: יש לנו Controller, Service, Repository וכו', גם אם בפועל ה-Service (לדוגמה) לא מוסיף שום ערך מעבר למה שה-Repository כבר מספק. התוצאה היא שכבת ביניים שמסבכת את המערכת סתם.

לדוגמה, תסתכלו על הקוד הבא שבו יש Service שלא עושה יותר מהפניה למאגר נתונים:

class OrderService {
  constructor(private orderRepo: OrderRepository) {}
  
  async getOrderDetails(id: string) {
    // שכבת Service שלא מוסיפה שום לוגיקה משל עצמה
    return this.orderRepo.findById(id);
  }
}

במקרה הזה, המחלקה OrderService לא מבצעת שום עיבוד או לוגיקה משל עצמה. היא פשוט עוטפת קריאה ל-orderRepo. אם ה-controller שלנו קורא רק ל-OrderService.getOrderDetails, יכולנו באותה מידה לקרוא ישירות ל-orderRepo.findById ולוותר על השכבה הזאת לחלוטין.

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

טעות #5: חשיפת הדומיין למימושים חיצוניים

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

סימן אזהרה מיידי הוא אם אתם מוצאים בקוד הדומיין import של ספריות כמו Express, Mongoose, Axios או כל framework חיצוני אחר. למשל, אם יש לנו מחלקת ישות (Entity) שבנויה ישירות על מודל של ORM, או פונקציה בדומיין שקוראת ל-API חיצוני בעזרת ספריית HTTP – זה אומר שחשפנו את הדומיין שלנו למימוש חיצוני.

ניקח דוגמה: נניח שמישהו שם את הגדרת מודל המשתמש של Mongoose בתוך קוד הדומיין, ואז משתמש בו ישירות כדי לאחזר נתונים:

// טעות: מודל Mongoose המשולב בליבת הדומיין
import mongoose from 'mongoose';

const UserSchema = new mongoose.Schema({
  name: String,
  email: String
});
export const UserModel = mongoose.model('User', UserSchema);

// שימוש במודל החיצוני בתוך פונקציית דומיין:
export async function getUserName(id: string): Promise<string | null> {
  const userDoc = await UserModel.findById(id);  // תלות ישירה ב-Mongoose בתוך הדומיין
  return userDoc ? userDoc.name : null;
}

בדוגמה הזו, UserModel (שהוא חלק מ-Mongoose) זמין ישירות בקוד הלוגיקה העסקית (getUserName). המשמעות היא שהדומיין שלנו עכשיו תלוי בפרטי מימוש של בסיס הנתונים (MongoDB במקרה זה). אם מחר נרצה להחליף מסד נתונים, או אפילו רק לבדוק את הלוגיקה הזו בלי גישה לבסיס נתונים, אנחנו בבעיה.

כדי להימנע מחשיפת הדומיין, עלינו להקפיד שהכיוון תמיד יהיה כזה: הדומיין מגדיר חוזים (ממשקים), והחוץ מממש אותם. למשל, במקרה של מסד נתונים הדומיין יכול להגדיר ממשק UserRepository מופשט, וההטמעה של Mongoose תיעשה בשכבת ה-Repository שב-Infrastructure. כך הלוגיקה העסקית (getUserName וכדומה) תקרא לפונקציות של UserRepository שאינן תלויות בטכנולוגיה, ואלו בתורן יקראו בפועל ל-Mongoose. באופן דומה, אם הדומיין צריך לקרוא ל-Service חיצוני (API למשל), נגדיר ממשק מתאים ונממש אותו בשכבה חיצונית. בקיצור, הדומיין נשאר "נקי" מטכנולוגיות, ומקבל רק את מה שהוא צריך.

סיכום: לאזן בין העקרונות לאפקטיביות היומיומית

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

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

ארכיטקטורה נקייה היא רק כלי בארגז הכלים שלנו – לא מטרה בפני עצמה. השתמשו בה בחוכמה, למדו מהטעויות הנפוצות, והיו מוכנים גם לחרוג מעט "מהספר" כשצריך. בסופו של דבר, השאיפה היא למצוא את הנקודה שבה המערכת גם בנויה נכון ויציבה, וגם מאפשרת לכם ולצוות שלכם להיות פרודוקטיביים ביום־יום. בהצלחה בבניית הארכיטקטורה הנקייה (והפרקטית) שלכם!

מהי ארכיטקטורה נקייה ומה המטרה שלה?

הקדמה

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

זה בדיוק מה שארכיטקטורה נקייה באה לפתור.

רגע, מה זה בכלל ארכיטקטורה נקייה?

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

איך זה נראה בפועל?

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

Entities (יישויות) – אלו הם האובייקטים הבסיסיים ביותר במערכת, כמו משתמשים, הזמנות, מוצרים וכדומה. כאן נמצאים המודלים העסקיים הטהורים, ללא שום קשר לטכנולוגיות או תשתיות ספציפיות.
Use Cases (מקרי שימוש) – השכבה הזו מגדירה את הפעולות או התהליכים שהמערכת יודעת לבצע באמצעות אותן ישויות. לדוגמה, "יצירת הזמנה חדשה", "רישום משתמש" או "עדכון פרטי מוצר". כאן נמצאת הלוגיקה העסקית עצמה.
Interface Adapters (מתאמי ממשק) – השכבה הזו מתווכת בין הליבה העסקית (Use Cases ו-Entities) לבין העולם החיצוני. למשל, היא מתרגמת מידע שמגיע מהמשתמש לתוך המערכת ומכינה נתונים פנימיים להצגה החוצה.
Frameworks & Drivers (מסגרות ותשתיות) – השכבה החיצונית ביותר, שכוללת את כל הכלים והטכנולוגיות החיצוניות, כמו בסיסי נתונים, שרתי HTTP, או ספריות חיצוניות שונות.

הכלל הכי חשוב בארכיטקטורה נקייה

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

ולמה כל זה שווה לנו?

יש כמה יתרונות מאוד גדולים לשימוש בארכיטקטורה נקייה:

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

בואו נראה דוגמה קצרה ב־TypeScript ו־Node.js

הנה דוגמה פשוטה להמחיש את העיקרון של ארכיטקטורה נקייה:

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

// זה ממשק מופשט בשכבת הליבה
interface IUserRepository {
  save(user: User): Promise<void>;
  getById(id: string): Promise<User | null>;
}

// אובייקט עסקי פשוט
class User {
  constructor(public id: string, public name: string) {}
}

// שכבת הלוגיקה העסקית (Use Case)
class CreateUser {
  constructor(private repo: IUserRepository) {}

  async execute(user: User) {
    if (!user.name) throw new Error('Name is required');
    await this.repo.save(user);
  }
}

עכשיו, בשכבת התשתית, נממש את הממשק הזה באמצעות MongoDB, למשל:

// מימוש של הממשק עבור MongoDB (שכבת תשתית חיצונית)
class MongoUserRepository implements IUserRepository {
  async save(user: User): Promise<void> {
    const collection = mongo.db('app').collection('users');
    await collection.insertOne(user);
  }

  async getById(id: string): Promise<User | null> {
    const collection = mongo.db('app').collection('users');
    return await collection.findOne({ id });
  }
}

ולבסוף, בהרכבת המערכת הראשית שלנו:

const userRepository = new MongoUserRepository();
const createUserUseCase = new CreateUser(userRepository);

await createUserUseCase.execute(new User('123', 'Aviv'));

שימו לב:
הקוד של CreateUser לא יודע כלום על MongoDB או על טכנולוגיה אחרת. הוא עובד רק מול ממשק מופשט (IUserRepository). זה כל הסוד – בידוד מוחלט של לוגיקה עסקית מטכנולוגיה חיצונית.

בשורה התחתונה – למי זה מתאים?

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

וכמו תמיד – אשמח לשמוע מכם בתגובות!
יש שאלות? רעיונות? משהו לא ברור? דברו איתי!