Differences

This shows you the differences between two versions of the page.

--- flight_booking_bff [2025/12/31 09:36] – [Node.js Folder Structure (Clean Architecture)] pradnya
+++ flight_booking_bff [2026/01/24 05:44] (current) – [Error Handling Strategy] madan
@@ Line 15: / Line 15: @@
 ==== Key Services / Core Components ====
-^Service^Responsibility|
+^Service^Responsibility^Local Port|
-|**API Gateway / BFF (Node.js)** |Single entry point for UI|
+|**API Gateway / BFF (Node.js)** |Single entry point for UI|4000|
-|**Auth Service** |Issues & validates tokens|
+|**Auth Service** |Issues & validates tokens|4001|
-|**Flight Service** |Calls supplier API + Redis cache|
+|**Flight Service** |Calls supplier API + Redis cache|4002|
-|**Booking Service (MySQL)** |Stores booking data|
+|**Booking Service (MySQL)** |Stores booking data|4003|
-|**Payment Service** |Payment initiation + webhooks|
+|**Payment Service** |Payment initiation + webhooks|4004|
 ==== Observability Stack ====
@@ Line 74: / Line 75: @@
 ^Layer^Purpose^Examples^Should define errors?|
 |**Domain** |Business rules|Entities, aggregates|**Business errors ** |
-|**Application** |Use-cases / orchestration|Services, DTOs|**App errors ** |
+|**Domain/Application** |Use-cases / orchestration|Services, DTOs|**App errors ** |
 |**Infrastructure** |Technical adapters|DB, Redis, HTTP|**Adapter-only errors ** |
 |**Interface/API** |Controllers|REST/GraphQL|no core errors|
@@ Line 503: / Line 504: @@
 </code>
 ====== Error Handling Strategy ======
-**  1. Client Errors (4xx)**
+**1. Client Errors (4xx)**
 ^Code^Meaning|
-|400|validation failure|
+|400|Bad Request/validation failure|
 |401|unauthorized|
 |404|cache expired|
@@ Line 527: / Line 529: @@
 |Payment declined|422|
 |Invalid state transition|409|
+===== Recommended Placement =====
+**1. ****Business / Domain Errors**
+When business rule is violeted -
+ <font inherit/inherit;;inherit;;#dddddd>/src/domain/errors</font>
+ <font 9px/inherit;;inherit;;inherit>ts</font>
+<code>
+export class FlightUnavailableError extends Error {
+  code = 'FLIGHT_UNAVAILABLE';
+}
+</code>
+**2. ****Application Errors**
+Use-case level\\
+Validation / workflow / orchestration
+/src/application/errors
+ <font 9px/inherit;;inherit;;inherit>ts</font>
+<code>
+export class ValidationError extends Error {
+  status = 400;
+  code = 'VALIDATION_ERROR';
+}
+</code>
+**3. ****Infrastructure Errors**
+ONLY for wrapping technical failures
+/src/infrastructure/errors
+ <font 9px/inherit;;inherit;;inherit>ts</font>
+<code>
+export class RedisConnectionError extends Error {
+  code = 'REDIS_CONNECTION_ERROR';
+}
+</code>
+BUT — these should usually be **mapped upward** into application-level errors.
+Example mapping:
+ <font 9px/inherit;;inherit;;inherit>ts</font>
+<code>
+try {
+   await redis.get(key);
+} catch(e) {
+   throw new CacheUnavailableError();
+}
+</code>
+So the **API layer never leaks Redis internals.**
+===== Error Flow (Best Practice) =====
+<code>
+Infrastructure error
+   ⬇ wrap / map
+Application error
+   ⬇ serialized to client
+HTTP response
+</code>
+final structure should look like
+<code>
+/src
+ ┣ /domain
+ ┃   ┗ /errors   ← Business rule errors
+ ┣ /application
+ ┃   ┗ /errors   ← Validation + workflow errors
+ ┣ /infrastructure
+ ┃   ┗ /errors   ← Technical adapter errors (wrapped)
+ ┗ /api (interfaces)
+     ┗ error-middleware.ts  ← converts to HTTP response
+</code>
+**What to AVOID**
+Defining all errors in ''infrastructure'' \\
+→ couples business logic to technology
+Throwing raw DB/Redis errors upward\\
+→ leaks internal details
+Mixed styles (sometimes returning strings, sometimes errors)\\
+→ debugging nightmare