For the complete documentation index, see llms.txt. This page is also available as Markdown.

Insert Example

Overview

This document demonstrates the complete Insert flow using the AddOrder feature from the EBusiness application. The flow starts with a POST request to the controller and ends with event publishing and subscriber processing.

Complete Flow Architecture

POST Request → Controller → Service → PreBus Plugins → Command Handler → Domain Model → Database → Event Publishing → Subscribers

Detailed Flow Breakdown

1. POST Request

2. Controller (API Entry Point)

3. Service Layer (Business Orchestration)

4. PreBus Processing (Validation Pipeline)
   ├── AddOrderSequence (Plugin Registration)
   ├── AddOrderDataPacket (Validation Context)
   └── ValidateCustomer Plugin (Business Rules)

5. Command Handler (Data Processing)

6. Domain Model (Business Logic)

7. Database (Data Persistence)

8. Event Publishing (Asynchronous Processing)

9. Subscribers (Side Effects)

Step-by-Step Implementation

1. API Controller - The Entry Point

File: OrdersController_AddOrder.cs

What Happens:

  • HTTP Method: POST /api/Orders/AddOrder

  • Input: AddOrderDto from request body

  • Action: Calls the service layer to process the order

  • Response: HTTP 201 Created with order ID

2. Service Layer - Business Orchestration

File: ProcessOrdersService_AddOrder.cs

What Happens:

  • PreBus Processing: Executes business rule sequences (plugins)

  • Validation: Processes business rule sequences

  • ID Generation: Generates unique order ID

  • Command Creation: Creates AddOrderCommand with DTO

  • Command Processing: Calls the command handler

  • Result: Returns success with generated order ID

2.1. PreBus Business Rule Sequence - Validation Pipeline

File: AddOrderSequence.cs

What Happens:

  • Plugin Registration: Registers validation plugins in execution order

  • Sequential Processing: Executes plugins one by one

  • Error Collection: Collects validation errors from all plugins

  • Early Exit: Stops processing if any plugin fails

2.2. PreBus Data Packet - Validation Context

File: AddOrderDataPacket.cs

What Happens:

  • Context Container: Holds DTO and application context

  • Error Collection: Collects validation errors from plugins

  • Data Sharing: Allows plugins to share data during validation

  • Logging: Provides logging capabilities for plugins

2.3. PreBus Validation Plugin - Business Rules

File: ValidateCustomer.cs

What Happens:

  • Business Rule Validation: Implements specific validation logic

  • Database Access: Can access repository for data validation

  • Error Reporting: Adds errors to the data packet if validation fails

  • Async Support: Supports asynchronous validation operations

  • Dependency Injection: Receives logger and repository factory

2.4. PreBus Plugin Benefits

  • Modular Validation: Each plugin handles one validation concern

  • Reusable Rules: Plugins can be reused across different features

  • Testable: Each plugin can be unit tested independently

  • Configurable: Plugins can be enabled/disabled per feature

  • Extensible: Easy to add new validation rules

  • Ordered Execution: Plugins execute in defined sequence

3. Command Handler - Data Processing

File: AddOrderHandler.cs

What Happens:

  • Context Setup: Initializes application context and repository

  • Domain Logic: Calls domain model to process business rules

  • Database Save: Inserts/updates the order in database

  • Logging: Logs success/failure of database operation

  • Event Publishing: Fires events for subscribers

4. Domain Model - Business Logic

File: Order/AddOrder.cs

What Happens:

  • Validation: Guards against null commands

  • Data Mapping: Converts DTO to domain model

  • Audit Fields: Sets created/modified by user

  • ID Assignment: Sets the generated ID

  • Business Rules: Calculates totals, sets order state

  • Child Objects: Processes order items

5. NServiceBus Handler - Message Processing

File: AddOrderNsbHandler.cs

What Happens:

  • Message Reception: Receives AddOrderCommand from message bus

  • Logging: Logs handler execution

  • Delegation: Calls the actual command handler

  • Context Bridge: Converts NServiceBus context to FlexBase context

6. Event Publishing - Asynchronous Processing

Event: OrderAddedEvent

What Happens:

  • Event Creation: FlexBase creates event with order data

  • Message Bus: Event is published to message bus

  • Subscriber Notification: All subscribers are notified

7. Event Subscribers - Side Effects

File: NotifyAccountsOnOrderAdded.cs

What Happens:

  • Event Reception: Receives OrderAddedEvent from message bus

  • Side Effects: Executes business logic (emails, notifications, etc.)

  • Additional Events: Can fire more events if needed

Data Transfer Objects (DTOs)

Input DTO: AddOrderDto

Command: AddOrderCommand

Flow Summary

Synchronous Flow (Immediate Response)

  1. POST Request → Controller receives request

  2. Service Processing → Business orchestration and PreBus validation

  3. PreBus Plugins → Sequential validation of business rules

  4. Command Handler → Data processing and database save

  5. Domain Logic → Business rules and calculations

  6. Response → HTTP 201 with order ID

Asynchronous Flow (Event Processing)

  1. Event Publishing → OrderAddedEvent published to message bus

  2. Subscriber Processing → NotifyAccountsOnOrderAdded executes

  3. Side Effects → Emails, notifications, inventory updates

  4. Additional Events → Can trigger more business processes

Key Benefits

  • Separation of Concerns: Each layer has a single responsibility

  • Testability: Each component can be tested independently

  • Scalability: Asynchronous processing handles high loads

  • Maintainability: Clear, readable code structure

  • Event-Driven: Loose coupling between components


This AddOrder example demonstrates how FlexBase enables clean, maintainable, and scalable insert operations with proper separation of concerns and event-driven architecture! 🚀

Last updated