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

Delete Example

Overview

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

Complete Flow Architecture

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

Detailed Flow Breakdown

1. DELETE Request

2. Controller (API Entry Point)

3. Service Layer (Business Orchestration)

4. PreBus Processing (Validation Pipeline)
   ├── DeleteProductSequence (Plugin Registration)
   ├── DeleteProductDataPacket (Validation Context)
   └── IsValidProduct 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: ProductsController_DeleteProduct.cs

What Happens:

  • HTTP Method: DELETE /api/Products/DeleteProduct/{id}

  • Input: Product ID from URL parameter

  • DTO Creation: Creates DeleteProductDto with the ID

  • Action: Calls the service layer to process the product deletion

  • Response: HTTP 200 OK with success status

2. Service Layer - Business Orchestration

File: ProcessProductsService_DeleteProduct.cs

What Happens:

  • PreBus Processing: Executes business rule sequences (plugins)

  • Validation: Processes business rule sequences

  • ID Generation: Generates unique key for tracking

  • Command Creation: Creates DeleteProductCommand with DTO

  • Command Processing: Calls the command handler

  • Result: Returns success status

2.1. PreBus Business Rule Sequence - Validation Pipeline

File: DeleteProductSequence.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: DeleteProductDataPacket.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: IsValidProduct.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

3. Command Handler - Data Processing

File: DeleteProductHandler.cs

What Happens:

  • Context Setup: Initializes application context and repository

  • Domain Logic: Calls domain model to process business rules

  • Null Check: Handles case where product doesn't exist

  • Database Save: Updates the product in database (soft delete)

  • Logging: Logs success/failure of database operation

  • Event Publishing: Fires events for subscribers

4. Domain Model - Business Logic

File: Product/DeleteProduct.cs

What Happens:

  • Validation: Guards against null commands

  • ID Assignment: Sets the product ID from DTO

  • State Management: Marks entity as deleted (soft delete)

  • Child Objects: Processes child object deletions

5. NServiceBus Handler - Message Processing

File: DeleteProductNsbHandler.cs

What Happens:

  • Message Reception: Receives DeleteProductCommand 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: ProductDeletedEvent (if implemented)

What Happens:

  • Event Creation: FlexBase creates event with product data

  • Message Bus: Event is published to message bus

  • Subscriber Notification: All subscribers are notified

7. Event Subscribers - Side Effects

File: NotifyInventoryOnProductDeleted.cs (if implemented)

What Happens:

  • Event Reception: Receives ProductDeletedEvent from message bus

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

  • Additional Events: Can fire more events if needed

Data Transfer Objects (DTOs)

Input DTO: DeleteProductDto

Command: DeleteProductCommand

Key Differences from Insert/Update Flow

Delete-Specific Characteristics

  1. URL Parameter: ID comes from URL path instead of request body

  2. DTO Creation: Controller creates DTO with ID from URL

  3. Soft Delete: Uses SetDeleted() instead of SetAdded() or SetModified()

  4. State Management: Marks entity as deleted (soft delete pattern)

  5. HTTP Method: Uses DELETE instead of POST or PUT

  6. Minimal Data: Only requires ID for deletion

PreBus Validation Focus

  • IsValidProduct: Validates product exists and can be deleted

  • Business Rules: Ensures product can be removed (not in use, not referenced)

  • Data Integrity: Validates deletion doesn't violate business constraints

Soft Delete Pattern

  • Database: Entity is marked as deleted, not physically removed

  • Queries: Soft-deleted entities are filtered out of normal queries

  • Recovery: Deleted entities can be restored if needed

  • Audit Trail: Maintains complete history of deletions

Flow Summary

Synchronous Flow (Immediate Response)

  1. DELETE Request → Controller receives request with ID

  2. Service Processing → Business orchestration and PreBus validation

  3. PreBus Plugins → Sequential validation of business rules

  4. Command Handler → Data processing and soft delete

  5. Domain Logic → Business rules and state management

  6. Response → HTTP 200 OK with success status

Asynchronous Flow (Event Processing)

  1. Event Publishing → ProductDeletedEvent published to message bus

  2. Subscriber Processing → NotifyInventoryOnProductDeleted executes

  3. Side Effects → Inventory updates, supplier notifications, analytics

Key Benefits

  • Data Safety: Soft delete preserves data for recovery

  • Business Rules: Validates deletion is allowed

  • Audit Trail: Tracks who deleted what and when

  • Event-Driven: Notifies other systems of deletions

  • Testable: Each component can be tested independently

  • Maintainable: Clear separation of concerns


This DeleteProduct example demonstrates how FlexBase enables clean, maintainable, and scalable delete operations with proper validation, soft delete patterns, and event-driven architecture! 🚀

Last updated