+ 
+
+ **Deterministic blueprints for traditional N-Tier applications.**
+
+
+---
+## 🗺️ Map of Patterns (Layered Modules)
+
+This architecture organizes the system into horizontal layers, where each layer has a specific role (Presentation, Business Logic, Data Access). It relies on strict top-to-bottom dependency flow.
+
+- 🌊 **Data Flow:** Presentation -> Logic -> Data -> Database.
+- 📁 **Folder Structure:** Separation by technical concern rather than business domain.
+- ⚖️ **Trade-offs:** Simplicity vs. High Coupling.
+- 🛠️ **Implementation Guide:** Rules for defining strict layer boundaries.
+
+## 📐 Architecture Diagram
+
+```mermaid
+graph TD
+ Presentation[Presentation Layer / Controllers] --> Business[Business Layer / Services]
+ Business --> Data[Data Access Layer / Repositories]
+ Data --> DB[(Database)]
+
+ %% Added Design Token Styles for Mermaid Diagrams
+ classDef default fill:#e1f5fe,stroke:#03a9f4,stroke-width:2px,color:#000;
+ classDef component fill:#e8f5e9,stroke:#4caf50,stroke-width:2px,color:#000;
+ classDef layout fill:#f3e5f5,stroke:#9c27b0,stroke-width:2px,color:#000;
+
+ class Presentation component;
+ class Business component;
+ class Data component;
+ class DB default;
+```
+
+## 🧱 Core Principles
+
+1. **Separation of Concerns:** Each layer handles a specific aspect of the application.
+2. **Top-to-Bottom Flow:** Higher layers can depend on lower layers, but lower layers MUST NOT depend on higher layers.
+3. **Closed Layers:** Requests must pass through each layer sequentially without skipping layers (to enforce validation and business rules).
+
+---
+
+## 🚧 1. Layer Bypass (The Wormhole Anti-pattern)
+
+### ❌ Bad Practice
+```typescript
+class UserController {
+ constructor(private readonly db: Database) {}
+
+ async getUser(req: Request, res: Response) {
+ // Skipping the Business Layer and accessing Data Layer directly
+ const user = await this.db.query(`SELECT * FROM users WHERE id = ${req.params.id}`);
+ return res.json(user);
+ }
+}
+```
+
+### ⚠️ Problem
+Bypassing the Business Logic layer directly from the Presentation layer creates a "wormhole." This leads to fragmented business rules, duplicated code, and difficulty in testing, as authorization or domain validations that should exist in the Business layer are skipped entirely.
+
+### ✅ Best Practice
+
+> [!NOTE]
+> **Internal Routing:** For more context, refer back to the [Architecture Map](../readme.md).
+
+```typescript
+// 1. Presentation Layer (Controller) handles HTTP
+class UserController {
+ constructor(private readonly userService: UserService) {}
+
+ async getUser(req: Request, res: Response) {
+ // Delegates to the Business Layer
+ const user = await this.userService.getUserById(req.params.id);
+ return res.json(user);
+ }
+}
+
+// 2. Business Layer (Service) handles logic
+class UserService {
+ constructor(private readonly userRepository: UserRepository) {}
+
+ async getUserById(id: string) {
+ if (!isValidId(id)) throw new Error("Invalid ID");
+ // Delegates to the Data Access Layer
+ return this.userRepository.findById(id);
+ }
+}
+
+// 3. Data Access Layer (Repository) handles DB
+class UserRepository {
+ constructor(private readonly db: Database) {}
+
+ async findById(id: string) {
+ return this.db.query(`SELECT * FROM users WHERE id = ${id}`);
+ }
+}
+```
+
+### 🚀 Solution
+Strictly enforce "Closed Layers". Every request from the Presentation layer MUST go through the Business Logic layer before reaching the Data Access layer. This guarantees that all business constraints and validations are deterministically applied, creating a predictable execution flow for AI Agents.
diff --git a/architectures/micro-frontends/folder-structure.md b/architectures/micro-frontends/folder-structure.md
index 2e5133a..845bfbb 100644
--- a/architectures/micro-frontends/folder-structure.md
+++ b/architectures/micro-frontends/folder-structure.md
@@ -46,7 +46,7 @@ workspace/
-### Structural Comparison: Monorepo vs Polyrepo for MFEs
+### ⚖️ Structural Comparison: Monorepo vs Polyrepo for MFEs
| Feature | Monorepo (Workspace) | Polyrepo (Independent Repos) |
| :--- | :--- | :--- |
diff --git a/architectures/micro-frontends/readme.md b/architectures/micro-frontends/readme.md
index c8d0f1f..9fb0f33 100644
--- a/architectures/micro-frontends/readme.md
+++ b/architectures/micro-frontends/readme.md
@@ -16,17 +16,17 @@ last_updated: 2026-03-22
This engineering directive defines the **best practices** for the Micro-frontends architecture. This document is designed to ensure maximum scalability, security, and code quality when developing enterprise-level frontend applications.
-# Context & Scope
+# 🎯 Context & Scope
- **Primary Goal:** Provide strict architectural rules and practical patterns for breaking down a monolithic frontend into independent, deployable micro-applications.
- **Description:** An architectural style where independently deliverable frontend applications are composed into a greater whole. This enables multiple teams to work simultaneously without stepping on each other's toes.
-## Map of Patterns
+## 🗺️ Map of Patterns
- 📊 [**Data Flow:** Request and Event Lifecycle](./data-flow.md)
- 📁 [**Folder Structure:** Layering logic](./folder-structure.md)
- ⚖️ [**Trade-offs:** Pros, Cons, and System Constraints](./trade-offs.md)
- 🛠️ [**Implementation Guide:** Code patterns and Anti-patterns](./implementation-guide.md)
-## Core Principles
+## 🧱 Core Principles
1. **Independent Deployments:** Each micro-frontend must be deployable on its own without requiring a redeployment of the entire system.
2. **Technology Agnostic (Optional but powerful):** Different teams can use different frameworks (React, Vue, Angular) if necessary, though standardization is recommended for performance.
@@ -45,7 +45,7 @@ graph LR
---
-## 1. Global State Coupling
+## 🚧 1. Global State Coupling
### ❌ Bad Practice
```javascript
@@ -84,7 +84,7 @@ Communication between micro-frontends must be asynchronous and event-driven. Usi
---
-## Architecture Diagram
+## 📐 Architecture Diagram
```mermaid
graph TD
diff --git a/architectures/microkernel-architecture/readme.md b/architectures/microkernel-architecture/readme.md
index 20fbc2e..61e1371 100644
--- a/architectures/microkernel-architecture/readme.md
+++ b/architectures/microkernel-architecture/readme.md
@@ -12,7 +12,7 @@ last_updated: 2026-04-18
[🏠 На главную](../README.md)
-# Context & Scope
+# 🎯 Context & Scope
- **Primary Goal:** Document and strictly enforce best practices for Microkernel (Plugin) Architecture to ensure deterministic system extensibility.
- **Target Tooling:** AI Agents and Human Developers.
- **Tech Stack Version:** Agnostic
@@ -60,7 +60,7 @@ Microkernel Architecture strictly isolates essential business rules (the Core) f
---
-## 1. Core-Plugin Boundary Enforcement
+## 🚧 1. Core-Plugin Boundary Enforcement
### ❌ Bad Practice
```typescript
diff --git a/architectures/microservices/implementation-guide.md b/architectures/microservices/implementation-guide.md
index 76b9b77..a6304c5 100644
--- a/architectures/microservices/implementation-guide.md
+++ b/architectures/microservices/implementation-guide.md
@@ -24,7 +24,7 @@ classDiagram
Gateway --> Service : RPC/HTTP
```
-## 1. Synchronous Cascading Calls
+## 🚧 1. Synchronous Cascading Calls
### ❌ Bad Practice
```typescript
diff --git a/architectures/microservices/readme.md b/architectures/microservices/readme.md
index f7cad4d..04bc517 100644
--- a/architectures/microservices/readme.md
+++ b/architectures/microservices/readme.md
@@ -15,16 +15,16 @@ last_updated: 2026-03-29
---
This engineering directive defines the **best practices** for the Microservices architecture. This document is designed to ensure maximum scalability, security, and code quality when developing enterprise-level applications.
-# Context & Scope
+# 🎯 Context & Scope
- **Primary Goal:** Provide strict architectural rules and practical patterns for creating scalable systems.
- **Description:** Breaking down a giant monolithic system into small, independent pieces, each handling its own business capability. Each service has its own Database.
-## Map of Patterns
+## 🗺️ Map of Patterns
- 📊 [**Data Flow:** Request and Event Lifecycle](./data-flow.md)
- 📁 [**Folder Structure:** Layering logic](./folder-structure.md)
- ⚖️ [**Trade-offs:** Pros, Cons, and System Constraints](./trade-offs.md)
- 🛠️ [**Implementation Guide:** Code patterns and Anti-patterns](./implementation-guide.md)
-### Structural Comparison: Microservices vs SOA (Service-Oriented Architecture)
+### ⚖️ Structural Comparison: Microservices vs SOA (Service-Oriented Architecture)
| Feature | Microservices | SOA |
| :--- | :--- | :--- |
@@ -33,7 +33,7 @@ This engineering directive defines the **best practices** for the Microservices
| **Data Storage** | Database per service (Strict isolation) | Often shares data storage |
| **Coupling** | Loosely coupled | Moderately to tightly coupled |
-## Core Principles
+## 🧱 Core Principles
1. **Isolation & Testability:** Changing a single feature doesn't break the entire business process.
2. **Strict Boundaries:** Enforce rigid structural barriers between business logic and infrastructure.
@@ -58,7 +58,7 @@ graph LR
class A,B,C default;
```
-## 1. Shared Database Across Services
+## 🚧 1. Shared Database Across Services
### ❌ Bad Practice
```yaml
diff --git a/architectures/model-view-controller/readme.md b/architectures/model-view-controller/readme.md
index 878e662..c4f8dfb 100644
--- a/architectures/model-view-controller/readme.md
+++ b/architectures/model-view-controller/readme.md
@@ -15,7 +15,7 @@ last_updated: 2026-03-22
---
This engineering directive defines the **best practices** for the MVC architecture. This document is designed to ensure maximum scalability, security, and code quality when developing enterprise-level applications.
-# Context & Scope
+# 🎯 Context & Scope
- **Primary Goal:** Provide strict architectural rules and 20 practical patterns for creating scalable and deterministic MVC applications.
- **Target Tooling:** AI Agents (Cursor, Windsurf, Copilot, Antigravity) and Senior Developers.
- **Tech Stack Version:** Agnostic (Applicable to Node.js, NestJS, Express, Spring Boot, Django, ASP.NET, etc.).
@@ -54,12 +54,12 @@ graph TD
```
---
-## Map of Patterns
+## 🗺️ Map of Patterns
- 📊 [**Data Flow:** Request and Event Lifecycle](./data-flow.md)
- 📁 [**Folder Structure:** Layering logic](./folder-structure.md)
- ⚖️ [**Trade-offs:** Pros, Cons, and System Constraints](./trade-offs.md)
- 🛠️ [**Implementation Guide:** Code patterns and Anti-patterns](./implementation-guide.md)
-## 1. Fat Controllers (God Object Controller)
+## 🚧 1. Fat Controllers (God Object Controller)
### ❌ Bad Practice
```typescript
@@ -99,7 +99,7 @@ class UserController {
### 🚀 Solution
Adhere to the 'Thin Controllers' paradigm. Delegate all business scenarios to a dedicated Service Layer or aggregate domain models.
---
-## 2. Anemic Domain Model
+## 🚧 2. Anemic Domain Model
### ❌ Bad Practice
```typescript
@@ -137,7 +137,7 @@ class Order {
### 🚀 Solution
Encapsulate internal state mutations within the Model itself (Rich Model). External services must invoke the model's action methods via established contracts rather than overriding its data directly.
---
-## 3. Direct Model Exposure to View
+## 🚧 3. Direct Model Exposure to View
### ❌ Bad Practice
```typescript
@@ -167,7 +167,7 @@ class UserController {
### 🚀 Solution
Architecturally, it is mandatory to use DTO (Data Transfer Object) or ViewModel classes to isolate the transformation of the domain model into a client-safe structure (View / API).
---
-## 4. Complex Logic within Views
+## 🚧 4. Complex Logic within Views
### ❌ Bad Practice
```html
@@ -195,7 +195,7 @@ The View layer gets infected with business computations (calculating access righ
### 🚀 Solution
Export aggregated states for the presentation layer (View) via a Presenter (ViewModel). The View must remain 'Dumb', capable only of rendering boolean flags and arrays of DTOs.
---
-## 5. View Layer Initiating Database Transactions
+## 🚧 5. View Layer Initiating Database Transactions
### ❌ Bad Practice
```typescript
@@ -221,7 +221,7 @@ class UserController {
### 🚀 Solution
The dependency vector of the View layer is strictly unidirectional 'Top-Down', relying on data injected by the Controller. The View must not be aware of the existence of any Storage (Repositories/DBs).
---
-## 6. Global State and Singletons Bound to Models
+## 🚧 6. Global State and Singletons Bound to Models
### ❌ Bad Practice
```typescript
@@ -250,7 +250,7 @@ class Invoice {
### 🚀 Solution
Eliminate the use of global Singletons within the domain area. All external parameters or environment configurations must be passed to models transparently (explicit dependencies) via constructors or method arguments.
---
-## 7. Mixing Low-Level Routing with Controller Logic
+## 🚧 7. Mixing Low-Level Routing with Controller Logic
### ❌ Bad Practice
```typescript
@@ -279,7 +279,7 @@ router.get('/settings', userController.showSettings);
### 🚀 Solution
Leave routing to the framework or a dedicated Router layer. The Controller's job is to respond to an already formed method call with a prepared payload.
---
-## 8. Validation Rules Leaking into the Domain Layers
+## 🚧 8. Validation Rules Leaking into the Domain Layers
### ❌ Bad Practice
```typescript
@@ -310,7 +310,7 @@ class UserController {
### 🚀 Solution
Syntax and format validation (JSON Schema, DTO Validation) must be performed at the request processing layer (Gateways / Controllers). Services must receive strictly deterministic data formats.
---
-## 9. Lack of Dependency Injection in Controllers
+## 🚧 9. Lack of Dependency Injection in Controllers
### ❌ Bad Practice
```typescript
@@ -336,7 +336,7 @@ class OrderController {
### 🚀 Solution
Utilize the Dependency Injection (DI) pattern. Controllers request required services or repositories via interfaces (IoC Containers), guaranteeing the ability to hot-swap abstractions.
---
-## 10. Generating Raw HTML Strings Inside Controllers
+## 🚧 10. Generating Raw HTML Strings Inside Controllers
### ❌ Bad Practice
```typescript
@@ -364,7 +364,7 @@ class WelcomeController {
### 🚀 Solution
The Controller NEVER generates markup directly. Its functional contract is to pass data structures (ViewModel / JSON) to a standardized templating engine (Handlebars, React Server, EJS).
---
-## 11. God Models (Monolithic Bounded Contexts)
+## 🚧 11. God Models (Monolithic Bounded Contexts)
### ❌ Bad Practice
```typescript
@@ -390,7 +390,7 @@ class PdfGeneratorService { ... }
### 🚀 Solution
Decompose god models into focused aggregates within strict Bounded Contexts.
---
-## 12. View Layer Mutating Upstream State
+## 🚧 12. View Layer Mutating Upstream State
### ❌ Bad Practice
```typescript
@@ -412,7 +412,7 @@ The View mutates the Model's state, bypassing the Controller and failing to noti
### 🚀 Solution
The MVC pattern dictates that the View is merely a Read-only Projection of the current data. For mutations, the View must send an instruction to the Controller (HTTP Request, Event), which then authorizes the process.
---
-## 13. Hardwired Environment Secrets within Logic Code
+## 🚧 13. Hardwired Environment Secrets within Logic Code
### ❌ Bad Practice
```typescript
@@ -440,7 +440,7 @@ class BillingService {
### 🚀 Solution
Hardcoding any environment variables (Passwords, URLs, Tokens) in Controllers and Models is forbidden. All infrastructure configuration must be loaded from a specialized configuration provider.
---
-## 14. Blocking Main Thread in Standard Controllers
+## 🚧 14. Blocking Main Thread in Standard Controllers
### ❌ Bad Practice
```typescript
@@ -470,7 +470,7 @@ class ReportController {
### 🚀 Solution
Integrate Job systems (RabbitMQ, Redis Queues). The Controller must delegate resource-intensive tasks to background workers and immediately return HTTP 202 (Accepted).
---
-## 15. The "Repository" Abstraction Leak to View/Controller
+## 🚧 15. The "Repository" Abstraction Leak to View/Controller
### ❌ Bad Practice
```typescript
@@ -500,7 +500,7 @@ class DashboardController {
### 🚀 Solution
Shield the View and Controller layers from low-level I/O operations. Integrate Repository / Data Access Object (DAO) patterns.
---
-## 16. Exposing Sequent Database Identifiers (IDOR Threat)
+## 🚧 16. Exposing Sequent Database Identifiers (IDOR Threat)
### ❌ Bad Practice
```typescript
@@ -523,7 +523,7 @@ class TransactionResponse {
### 🚀 Solution
Translate internal physical database identifiers (Integers) into external string UUIDs or hashes before the Controller passes them to the View.
---
-## 17. Duplicating Core Invariants Inside Templates
+## 🚧 17. Duplicating Core Invariants Inside Templates
### ❌ Bad Practice
```typescript
@@ -547,7 +547,7 @@ Duplicating business system domain invariants. If the weight threshold changes t
> [!IMPORTANT]
> The Domain Model is the single "Source of Truth". The View MUST read pre-computed polymorphic state provided by the system.
---
-## 18. Side-Effects Orchestration Inside Controller Scope
+## 🚧 18. Side-Effects Orchestration Inside Controller Scope
### ❌ Bad Practice
```typescript
@@ -581,7 +581,7 @@ class SubscriptionController {
> [!IMPORTANT]
> Implement Domain Events Architectures (Pub/Sub brokers). The Controller is strictly responsible for initiating the "Payment complete" business event; dispatch logic MUST not block the response channel to the client.
---
-## 19. Fractured Exception Logging (Try-Catch Hell)
+## 🚧 19. Fractured Exception Logging (Try-Catch Hell)
### ❌ Bad Practice
```typescript
@@ -613,7 +613,7 @@ class ItemController {
### 🚀 Solution
Abstract the Error Handling procedure into framework-level Global Exception Handlers, standardizing the format of HTTP 4XX / 5XX error responses for the View.
---
-## 20. Overusing the Model Segment for Hardware Infrastructure (AWS, FS)
+## 🚧 20. Overusing the Model Segment for Hardware Infrastructure (AWS, FS)
### ❌ Bad Practice
```typescript
diff --git a/architectures/monolithic-architecture/readme.md b/architectures/monolithic-architecture/readme.md
index f52bad6..5febf69 100644
--- a/architectures/monolithic-architecture/readme.md
+++ b/architectures/monolithic-architecture/readme.md
@@ -15,16 +15,16 @@ last_updated: 2026-03-22
---
Этот инженерный директив определяет **лучшие практики (best practices)** для архитектуры Monolithic Architecture. Данный документ спроектирован для обеспечения максимальной масштабируемости, безопасности и качества кода при разработке приложений корпоративного уровня.
-# Context & Scope
+# 🎯 Context & Scope
- **Primary Goal:** Предоставить строгие архитектурные правила и практические паттерны для создания масштабируемых систем.
- **Description:** The entire system components (Database, Message Queues, Business Logic, APIs) are deployed and operated from a single codebase on a single server.
-## Map of Patterns
+## 🗺️ Map of Patterns
- 📊 [**Data Flow:** Request and Event Lifecycle](./data-flow.md)
- 📁 [**Folder Structure:** Layering logic](./folder-structure.md)
- ⚖️ [**Trade-offs:** Pros, Cons, and System Constraints](./trade-offs.md)
- 🛠️ [**Implementation Guide:** Code patterns and Anti-patterns](./implementation-guide.md)
-### Structural Comparison: Monolithic Architecture vs Microservices
+### ⚖️ Structural Comparison: Monolithic Architecture vs Microservices
| Feature | Monolithic Architecture | Microservices |
| :--- | :--- | :--- |
@@ -34,7 +34,7 @@ last_updated: 2026-03-22
| **Complexity** | Lower initially, higher as it grows | Higher initially, manageable at scale |
| **Data Management** | Shared database | Database per service |
-## Architecture Diagram
+## 📐 Architecture Diagram
```mermaid
graph TD
@@ -53,13 +53,13 @@ graph TD
class Project layout;
```
-## Core Principles
+## 🧱 Core Principles
1. **Isolation & Testability:** Changing a single feature doesn't break the entire business process.
2. **Strict Boundaries:** Enforce rigid structural barriers between business logic and infrastructure.
3. **Decoupling:** Decouple how data is stored from how it is queried and displayed.
-## 1. Tightly Coupled Internal Modules (Spaghetti Code)
+## 🚧 1. Tightly Coupled Internal Modules (Spaghetti Code)
### ❌ Bad Practice
```typescript
diff --git a/architectures/readme.md b/architectures/readme.md
index 266a53a..04fefea 100644
--- a/architectures/readme.md
+++ b/architectures/readme.md
@@ -12,7 +12,7 @@ last_updated: 2026-03-29
[🏠 На главную](../README.md)
-# Context & Scope
+# 🎯 Context & Scope
- **Primary Goal:** Establish definitive rules and best practices for system design and architecture.
- **Target Tooling:** Cursor, Windsurf, Antigravity.
- **Tech Stack Version:** Agnostic
@@ -58,8 +58,9 @@ Don't know where to start? Here are a few golden rules:
- [Space-Based Architecture](./space-based-architecture/readme.md)
- [Serverless](./serverless/readme.md)
- [Agentic Architecture (AI Agent Orchestration)](./agentic-architecture/readme.md)
+- [Layered Architecture (N-Tier)](./layered-architecture/readme.md)
-## 🏆 Top 15 Best Architectural Approaches
+## 🏆 Top 16 Best Architectural Approaches
Below are the most popular architectural patterns along with examples, tips, technology stacks, and their logos. A Folder Tree is provided for each to give you a deep understanding of its structure.
---
@@ -719,3 +720,40 @@ src/
- **Frameworks:** Eclipse, VS Code, Webpack, Babel.
- **Languages:**
+
+ **Deterministic blueprints for traditional N-Tier applications.**
+
TypeScript, 
Java, 
Python.
- **Patterns / Principles:** Open/Closed Principle, Dependency Inversion, Registry Pattern.
+---
+
+### 17. Layered Architecture (N-Tier)
+[](#)
+
+**Description:** The traditional architecture where the system is organized into horizontal layers, each with a specific role (Presentation, Business Logic, Data Access).
+**📖 Map of Patterns:** [Go to Layered Architecture Guidelines](./layered-architecture/readme.md)
+
+**Architecture Diagram & Folder Tree:**
+```mermaid
+graph TD
+ Presentation[Presentation Layer / Controllers] --> Business[Business Layer / Services]
+ Business --> Data[Data Access Layer / Repositories]
+ Data --> DB[(Database)]
+
+ %% Added Design Token Styles for Mermaid Diagrams
+ classDef default fill:#e1f5fe,stroke:#03a9f4,stroke-width:2px,color:#000;
+ classDef component fill:#e8f5e9,stroke:#4caf50,stroke-width:2px,color:#000;
+ classDef layout fill:#f3e5f5,stroke:#9c27b0,stroke-width:2px,color:#000;
+
+ class Presentation component;
+ class Business component;
+ class Data component;
+ class DB default;
+```
+
+```text
+src/
+├── 📁 presentation/ # Controllers, Views, UI Routes
+├── 📁 business/ # Core business logic and Services
+└── 📁 data/ # Repositories and database access
+```
+
+**Best Compatibility:**
+- **Frameworks:** Spring Boot, Django, ASP.NET Core.
+- **Languages:** Java, 
C#.
+- **Patterns / Principles:** Separation of Concerns, Closed Layers.
diff --git a/architectures/serverless/readme.md b/architectures/serverless/readme.md
index e9a7e89..7331caa 100644
--- a/architectures/serverless/readme.md
+++ b/architectures/serverless/readme.md
@@ -15,23 +15,23 @@ last_updated: 2026-03-29
Этот инженерный директив определяет **лучшие практики (best practices)** для архитектуры Serverless. Данный документ спроектирован для обеспечения максимальной масштабируемости, безопасности и качества кода при разработке приложений корпоративного уровня.
-# Context & Scope
+# 🎯 Context & Scope
- **Primary Goal:** Предоставить строгие архитектурные правила и практические паттерны для создания масштабируемых систем.
- **Description:** Developers do not manage servers at all. The entire "server" consists of bite-sized pieces of business logic (functions/Lambdas) living in the cloud.
-## Map of Patterns
+## 🗺️ Map of Patterns
- 📊 [**Data Flow:** Request and Event Lifecycle](./data-flow.md)
- 📁 [**Folder Structure:** Layering logic](./folder-structure.md)
- ⚖️ [**Trade-offs:** Pros, Cons, and System Constraints](./trade-offs.md)
- 🛠️ [**Implementation Guide:** Code patterns and Anti-patterns](./implementation-guide.md)
-## Core Principles
+## 🧱 Core Principles
1. **Isolation & Testability:** Changing a single feature doesn't break the entire business process.
2. **Strict Boundaries:** Enforce rigid structural barriers between business logic and infrastructure.
3. **Decoupling:** Decouple how data is stored from how it is queried and displayed.
-## Architecture Diagram
+## 📐 Architecture Diagram
```mermaid
graph TD
@@ -51,7 +51,7 @@ graph TD
---
-## 1. The Monolithic Lambda (Fat Function)
+## 🚧 1. The Monolithic Lambda (Fat Function)
### ❌ Bad Practice
```javascript
@@ -94,7 +94,7 @@ Embrace the "Single Responsibility Principle" at the infrastructure level. Decom
---
-## 2. Stateful Execution Contexts
+## 🚧 2. Stateful Execution Contexts
### ❌ Bad Practice
```javascript
diff --git a/architectures/space-based-architecture/data-flow.md b/architectures/space-based-architecture/data-flow.md
index f8c2976..5be1850 100644
--- a/architectures/space-based-architecture/data-flow.md
+++ b/architectures/space-based-architecture/data-flow.md
@@ -16,15 +16,15 @@ last_updated: 2026-03-29
This document describes the request and event lifecycle in a Space-Based Architecture.
-## 1. Request Handling
+## 🚧 1. Request Handling
When a request enters the system, the API Gateway routes it to the Virtualized Middleware. The middleware then intelligently assigns the request to the appropriate Processing Unit based on the required operation and the partitioned data shard.
-## 2. In-Memory Execution
+## 🚧 2. In-Memory Execution
The Processing Unit receives the request and interacts almost exclusively with the In-Memory Data Grid (IMDG). Because the data is held in memory, read and write operations occur at microsecond speeds. No synchronous calls are made to persistent storage.
-## 3. Data Syncing
+## 🚧 3. Data Syncing
Modifications to the IMDG are captured and streamed via asynchronous Data Pumps. These background processes replicate the changes to a central Persistent Storage (Database). If a node fails, the data can be recovered from the persistent store to rehydrate the grid.
diff --git a/architectures/space-based-architecture/readme.md b/architectures/space-based-architecture/readme.md
index b0f14ac..08fd80f 100644
--- a/architectures/space-based-architecture/readme.md
+++ b/architectures/space-based-architecture/readme.md
@@ -16,17 +16,17 @@ last_updated: 2026-03-29
This engineering directive defines the **best practices** for the Space-Based Architecture (SBA). This document is designed to ensure maximum scalability, security, and code quality when developing applications that require extreme high-performance and low-latency under unpredictable, fluctuating user loads.
-# Context & Scope
+# 🎯 Context & Scope
- **Primary Goal:** Provide strict architectural rules and practical patterns for building systems that rely on distributed in-memory data grids to eliminate database bottlenecks.
- **Description:** A pattern designed to minimize the constraints of a central database by keeping state in an in-memory data grid. The architecture relies on "processing units" that independently execute logic and communicate with each other or the grid.
-## Map of Patterns
+## 🗺️ Map of Patterns
- 📊 [**Data Flow:** Request and Event Lifecycle](./data-flow.md)
- 📁 [**Folder Structure:** Layering logic](./folder-structure.md)
- ⚖️ [**Trade-offs:** Pros, Cons, and System Constraints](./trade-offs.md)
- 🛠️ [**Implementation Guide:** Code patterns and Anti-patterns](./implementation-guide.md)
-## Architecture Diagram
+## 📐 Architecture Diagram
```mermaid
graph TD
@@ -54,14 +54,14 @@ graph TD
---
-## Core Principles
+## 🧱 Core Principles
1. **Database Bottleneck Elimination:** Traditional central databases act as a choke point during high load. SBA completely avoids synchronous DB writes in the critical request path.
2. **In-Memory Data Grid (IMDG):** The state is aggressively cached and maintained in an IMDG, providing microsecond access times for Processing Units.
3. **Independent Processing Units:** Microservices or components that contain business logic and operate over small shards of data, executing autonomously.
4. **Asynchronous Persistence:** The IMDG eventually syncs data back to a persistent store in the background, out of the hot path.
-## 1. Synchronous Database Writes in Processing Units
+## 🚧 1. Synchronous Database Writes in Processing Units
### ❌ Bad Practice
```typescript