בפוסטים הקודמים בסדרה חקרנו את המבנה של ארכיטקטורה נקייה, השווינו אותה לארכיטקטורות אחרות, ודיברנו על עקרונות מעשיים ליישום. בשלב זה אתם בטח כבר נלהבים ליישם את העקרונות האלה בפרויקט שלכם. אבל כמו בכל פרקטיקה טובה, אפשר גם ליישם אותה בצורה לא נכונה. בפוסט הזה נמשיך את הסדרה בהתמקדות בטעויות נפוצות שצוותים עושים כשהם מיישמים ארכיטקטורה נקייה – וכמובן, איך להימנע מהן.
טעות #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 למשל), נגדיר ממשק מתאים ונממש אותו בשכבה חיצונית. בקיצור, הדומיין נשאר "נקי" מטכנולוגיות, ומקבל רק את מה שהוא צריך.
סיכום: לאזן בין העקרונות לאפקטיביות היומיומית
ארכיטקטורה נקייה מעניקה לנו קווים מנחים מצוינים לארגון הקוד, אבל כמו שראינו, חשוב גם להפעיל שיקול דעת. המטרה הסופית היא קוד שניתן לתחזק ולהרחיב בקלות, וגם לספק ערך עסקי במהירות וביעילות. לפעמים דבקות אדוקה מדי בכל כלל תאורטי יכולה להאט אותנו, ולפעמים קיצורי דרך מוגזמים יכולים ליצור כאוס בטווח הארוך. המפתח הוא למצוא את האיזון הנכון. זיכרו, לכל כלל יש יוצא מן הכלל, ולא מה שמתאים לצוות אחד מתאים לצוות אחר.
כשאתם מיישמים את העקרונות, זכרו למה אתם עושים את זה: כדי לשמור על הלוגיקה העסקית נקייה מתלות, כדי שהמערכת תהיה גמישה לשינויים, וכדי שלצוות יהיה קל לעבוד עליה. אם החלטה ארכיטקטורלית מסוימת לא משרתת את המטרות האלה – אל תהססו להתאים אותה או אפילו לוותר עליה. ומנגד, אם קיצרתם דרך והקוד מתחיל להסתבך, אולי הגיע הזמן להכניס חזרה קצת מהעקרונות.
ארכיטקטורה נקייה היא רק כלי בארגז הכלים שלנו – לא מטרה בפני עצמה. השתמשו בה בחוכמה, למדו מהטעויות הנפוצות, והיו מוכנים גם לחרוג מעט "מהספר" כשצריך. בסופו של דבר, השאיפה היא למצוא את הנקודה שבה המערכת גם בנויה נכון ויציבה, וגם מאפשרת לכם ולצוות שלכם להיות פרודוקטיביים ביום־יום. בהצלחה בבניית הארכיטקטורה הנקייה (והפרקטית) שלכם!
