ארכיטקטורת יישומי ווב: ייעוץ וריפקטורינג

src/
  modules/
    auth/ # Bounded Context: авторизация
      domain/
      application/
      infrastructure/
    billing/ # Bounded Context: оплата
    notifications/ # Bounded Context: уведомления
  shared/
    kernel/ # Общие примитивы (Money, UserId)
    infrastructure/ # DB, HTTP-клиенты

בפרויקט אחד לפלטפורמת קורסים מקוונים, בחרנו במונולית מודולרי. אחרי שנה, הצוות של 8 חילץ בקלות את שירות ההתראות למיקרוסרוויס נפרד בלי לשכתב את הליבה. המודולריות השתלמה: עלויות השינוי ירדו ב-40%.

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

איך לתכנן API כך שלא תצטרכו לשכתב אותו בעוד שנה

בחירת פרוטוקול API משפיעה על הביצועים ועל חוויית המפתח. tRPC הוא אופטימלי עבור יישומי Next.js/Nuxt מונוליתיים: RPC עם טיפוסיות בטוחה ללא יצירת קוד. GraphQL עבור APIs ציבוריים עם לקוחות מרובים. REST עבור אינטגרציות עם שירותים חיצוניים. tRPC צובר פופולריות ביישומי TypeScript, ומבטיח טיפוסיות מלאה ללא יצירת קוד.

דוגמת tRPC:

// server/routers/users.ts
const usersRouter = router({
  getById: publicProcedure
    .input(z.object({ id: z.string().uuid() }))
    .query(async ({ input }) => {
      return db.user.findUnique({
        where: { id: input.id },
      });
    }),
  create: protectedProcedure
    .input(createUserSchema)
    .mutation(async ({ input, ctx }) => {
      // ctx.user — авторизованный пользователь
    }),
});

// client/pages/users.tsx — типы разделяются автоматически
const { data } = trpc.users.getById.useQuery({ id: userId });

שימוש ב-tRPC מפחית את מספר הבאגים בגבול frontend–backend ב-40% הודות לטיפוסיות קפדנית. הירשמו לביקורת ארכיטקטורה כדי לשפר את איכות ה-API.

למה להפריד בין CQRS ו-Repository?

תבנית Repository עם Prisma מפרידה את לוגיקת גישת הנתונים מחוקי העסק. זה מפשט בדיקות והחלפת אחסון.

// domain/repositories/UserRepository.ts
interface UserRepository {
  findById(id: UserId): Promise<User | null>;
  save(user: User): Promise<void>;
  findByEmail(email: Email): Promise<User | null>;
}

// infrastructure/prisma/PrismaUserRepository.ts
class PrismaUserRepository implements UserRepository {
  constructor(private readonly db: PrismaClient) {}

  async findById(id: UserId): Promise<User | null> {
    const record = await this.db.user.findUnique({ where: { id: id.value } });
    return record ? UserMapper.toDomain(record) : null;
  }
}

CQRS (Command Query Responsibility Segregation) מפריד בין פעולות שינוי וקריאת נתונים. עבור תחומים מורכבים, זה נותן גמישות: מודל הכתיבה יכול להיות שונה ממודל הקריאה, כל אחד מותאם לצרכיו. מרטין פאולר: "CQRS מתאים רק להקשרים מוגבלים עם מורכבות גבוהה." CQRS שימושי במיוחד כאשר מודלי הכתיבה והקריאה שונים מאוד—לדוגמה, במערכת הזמנת כרטיסים, פעולות כתיבה עוברות בדיקות קפדניות, בעוד פעולות קריאה מותאמות לחיפוש מהיר.

איך לארגן קאש ומשימות רקע

Cache-Aside הוא התבנית הנפוצה ביותר. נתונים נטענים לקאש בבקשה הראשונה ומתבטלים בעדכון. זמן התגובה הממוצע עם קאש יורד מ-200ms ל-5ms.

Write-Through מעדכן באופן סינכרוני גם את מסד הנתונים וגם את הקאש, ומבטיח עקביות.

// Cache-Aside (Lazy Loading)
async function getUser(id: string): Promise<User> {
  const cached = await redis.get(`user:${id}`);
  if (cached) return JSON.parse(cached);
  const user = await db.user.findUnique({ where: { id } });
  await redis.setex(`user:${id}`, 3600, JSON.stringify(user));
  return user;
}

// Write-Through (синхронное обновление кэша)
async function updateUser(id: string, data: UpdateUserDto): Promise<User> {
  const user = await db.user.update({ where: { id }, data });
  await redis.setex(`user:${id}`, 3600, JSON.stringify(user));
  return user;
}

למשימות רקע אנחנו משתמשים ב-BullMQ. תור עם ניסיונות חוזרים ועדיפויות הניתנים להגדרה.

// BullMQ: типизированные задачи
interface EmailJobData {
  to: string;
  template: 'welcome' | 'password-reset' | 'invoice';
  variables: Record<string, string>;
}

const emailQueue = new Queue<EmailJobData>('emails', {
  connection: redis
});

// Producer (из основного кода)
await emailQueue.add('send', {
  to: user.email,
  template: 'welcome',
  variables: { name: user.name }
}, {
  attempts: 3,
  backoff: { type: 'exponential', delay: 2000 }
});

// Consumer (отдельный воркер)
const worker = new Worker<EmailJobData>('emails', async (job) => {
  await emailService.send(job.data);
}, {
  connection: redis,
  concurrency: 5
});

מה כלול בייעוץ הארכיטקטורה

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

ייעוץ לארכיטקטורת פרויקט חדש—3–5 ימי עבודה. העלות מתחילה ב-$2,500, עם ממוצע של $4,000. ביקורת ארכיטקטורה קיימת—5–10 ימי עבודה תלוי בגודל המערכת, עם מחירים הנעים בין $3,000 ל-$7,000. אנחנו צוות עם ניסיון של מעל 10 שנים בארכיטקטורת יישומי ווב, שסיפקנו 50+ פרויקטים בסטארטאפים ובארגונים. קבלו ייעוץ כדי להניח את הבסיס הארכיטקטוני הנכון למוצר שלכם. צרו קשר כדי לדון בפרטים.