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