ποΈFeatures and Modules
π― Understanding Modules and Features
Flexbase organizes enterprise applications into Modules and Features - a clear, business-focused approach that maps directly to your requirements and user interface actions.
π¦ What is a Module?
A Module represents a complete business domain or functional area of your application. Think of it as a self-contained unit that handles all operations related to a specific business concept.
Examples of Modules:
π Orders Module - Complete order management
π¦ Products Module - Product catalog and inventory
π³ Payments Module - Payment processing
π₯ Customers Module - Customer management
π Reports Module - Analytics and reporting
β‘ What is a Feature?
A Feature represents a single business action or operation within a module. Every button click, form submission, or user action in your application typically maps to one feature.
Feature Examples:
Insert (POST):
AddOrder,CreateProduct,RegisterCustomerQuery (GET):
GetOrders,SearchProducts,GetCustomerDetailsUpdate (PUT):
UpdateOrder,ModifyProduct,EditCustomerDelete (DELETE):
CancelOrder,RemoveProduct,DeactivateCustomer
π Business Requirements β Technical Mapping
The Mapping Process:
Identify Business Domains β Create Modules
Identify User Actions β Create Features
Define Data Requirements β Create DTOs
Specify Business Rules β Create Domain Logic
π Real-World Example: E-Commerce Application
Let's walk through a complete example of how business requirements translate to Flexbase modules and features.
Business Requirements:
"We need an e-commerce system where customers can browse products, place orders, and make payments. Administrators should be able to manage products and view order reports."
π Module 1: Orders Module
Business Domain: Order Management
Purpose: Handle all order-related operations
Features in Orders Module:
1. AddOrder Feature (POST)
Business Requirement: "Customer clicks 'Place Order' button"
Screen Action: Customer fills order form and clicks "Place Order"
Technical Implementation:
API Endpoint: POST /api/Orders/AddOrder
2. GetOrders Feature (GET)
Business Requirement: "Admin clicks 'View Orders' to see all orders"
Screen Action: Admin navigates to Orders page
Technical Implementation:
π Database Optimization Magic - No Complex SQL Required!
The beauty of Flexbase queries is that you don't write complex SELECT statements! Here's what happens automatically:
1. Automatic Projection to Output Model
2. Database-Level Optimization
What Flexbase generates automatically:
3. Performance Benefits
β Only Required Fields - Database fetches only what's in your DTO
β Automatic Joins - Include() statements become optimized SQL JOINs
β No N+1 Queries - Single query with proper joins
β Memory Efficient - No unnecessary data loaded into memory
β Network Optimized - Less data transferred over the network
4. Complex Projections Made Simple
5. What You DON'T Have to Write
6. What You DO Write (Simple and Clean)
π― Key Benefits:
No SQL Knowledge Required - Write C# LINQ, get optimized SQL
Automatic Optimization - Only fetch what you need
Type Safety - Compile-time validation of all projections
Maintainable - Changes to DTO automatically update SQL
Performance - Database-level optimization without complexity
Readable - Business logic is clear and understandable
π‘ The Magic of SelectTo()
The SelectTo<GetOrdersDto>() method:
β Analyzes your DTO - Sees what fields you need
β Generates optimized SQL - Only selects required columns
β Handles joins automatically - Based on Include() statements
β Applies projections - Maps complex calculations
β Optimizes performance - Database-level efficiency
Result: You focus on business logic while Flexbase handles all the complex SQL optimization automatically!
API Endpoint: GET /api/Orders/GetOrders
π¦ Module 2: Products Module
Business Domain: Product Catalog Management
Purpose: Handle all product-related operations
Features in Products Module:
1. AddProduct Feature (POST)
Business Requirement: "Admin clicks 'Add New Product' button"
Screen Action: Admin fills product form and clicks "Save Product"
Technical Implementation:
API Endpoint: POST /api/Products/AddProduct
2. GetProducts Feature (GET)
Business Requirement: "Customer clicks 'Browse Products' to see available products"
Screen Action: Customer navigates to Products page
Technical Implementation:
API Endpoint: GET /api/Products/GetProducts
π― Screen-to-Feature Mapping Examples
Example 1: Customer Order Screen
"Place Order" Button
Click
AddOrder
POST
/api/Orders/AddOrder
"View My Orders" Link
Click
GetCustomerOrders
GET
/api/Orders/GetCustomerOrders
"Order Details" Link
Click
GetOrderDetails
GET
/api/Orders/GetOrderDetails
"Cancel Order" Button
Click
CancelOrder
PUT
/api/Orders/CancelOrder
Example 2: Admin Product Management Screen
"Add Product" Button
Click
AddProduct
POST
/api/Products/AddProduct
"Edit Product" Button
Click
UpdateProduct
PUT
/api/Products/UpdateProduct
"Delete Product" Button
Click
DeleteProduct
DELETE
/api/Products/DeleteProduct
"Search Products" Input
Type + Enter
SearchProducts
GET
/api/Products/SearchProducts
"Filter by Category" Dropdown
Select
GetProductsByCategory
GET
/api/Products/GetProductsByCategory
Example 3: Customer Dashboard Screen
"View Profile" Link
Click
GetCustomerProfile
GET
/api/Customers/GetCustomerProfile
"Edit Profile" Button
Click
UpdateCustomerProfile
PUT
/api/Customers/UpdateCustomerProfile
"Order History" Tab
Click
GetOrderHistory
GET
/api/Orders/GetOrderHistory
"Wishlist" Tab
Click
GetWishlist
GET
/api/Products/GetWishlist
ποΈ Complete Module Structure
Typical Module Contains:
π― Feature Development Workflow
Step 1: Identify Business Requirement
"Customer needs to be able to place an order"
Step 2: Map to Screen Action
"Customer clicks 'Place Order' button on order form"
Step 3: Define Feature
"AddOrder feature in Orders module"
Step 4: Generate Code
Step 5: Add Business Logic
Step 6: Test and Deploy
β Unit tests generated automatically
β Integration tests ready
β API documentation generated
β Ready for deployment
π Module Planning Template
For Each Business Domain, Ask:
What is the main business concept? β Module Name
What actions can users perform? β Features
What data is needed for each action? β DTOs
What business rules apply? β Domain Logic
What events should be published? β Domain Events
Example: Customer Management Module
Main Business Concept
Customer Management
User Actions
Register, Login, Update Profile, View Profile, Deactivate
Data Requirements
Name, Email, Phone, Address, Preferences
Business Rules
Email validation, Password requirements, Profile completeness
Events
CustomerRegistered, ProfileUpdated, CustomerDeactivated
π Best Practices
Module Design:
β Single Responsibility - One business domain per module
β Clear Boundaries - Minimal coupling between modules
β Consistent Naming - Follow business terminology
β Complete Coverage - All related features in one module
Feature Design:
β One Action Per Feature - Each feature does one thing
β Clear Input/Output - Well-defined DTOs
β Business Logic in Domain - Keep controllers thin
β Proper Validation - Validate at multiple levels
Naming Conventions:
Modules:
OrdersModule,ProductsModule,CustomersModuleFeatures:
AddOrder,GetOrders,UpdateProduct,DeleteCustomerDTOs:
AddOrderDto,GetOrdersDto,OrderDtoHandlers:
AddOrderHandler,GetOrdersHandler
π Summary
Flexbase Modules and Features provide a clear, business-focused approach to enterprise application development:
Modules = Business domains (Orders, Products, Customers)
Features = User actions (AddOrder, GetProducts, UpdateCustomer)
Screen Actions = Direct mapping to features
Business Requirements = Clear path to technical implementation
The result: A maintainable, scalable application that directly reflects your business needs and user interface requirements.
Start mapping your business requirements to Flexbase modules and features today. Transform your ideas into working enterprise applications in minutes, not months.
Last updated