Architecture Philosophy
Wolfix.Server is built as a modular monolith - a single deployable application composed of loosely coupled, highly cohesive modules. Each module represents a bounded context in the domain and follows Clean Architecture principles.Core Principles
Bounded Contexts
Each module encapsulates a specific business domain with clear boundaries
Explicit Dependencies
Modules communicate through well-defined integration events, not direct references
Layered Design
Every module follows the same layer structure: Domain, Application, Infrastructure, Endpoints
Shared Kernel
Common abstractions, value objects, and base classes live in Shared modules
Module Structure
Each business module follows a consistent 4-layer architecture:Available Modules
Business Modules
Identity
Identity
Authentication, authorization, and user account management. Handles registration, login, JWT tokens, and role management.
Catalog
Catalog
Product catalog, categories, variants, attributes, reviews, and discounts. Central to the e-commerce domain.
Order
Order
Order processing, delivery methods, payment tracking, and order lifecycle management.
Customer
Customer
Customer profiles, shopping carts, favorites, bonuses, and violation tracking.
Seller
Seller
Seller accounts, seller applications, categories, and seller-specific operations.
Media
Media
Blob storage management for photos and videos using Azure Blob Storage.
Support
Support
Support tickets, requests categorization (bugs, orders, general), and support agent management.
Admin
Admin
Administrative accounts and operations (Basic and Super admin types).
Inter-Module Communication
Modules communicate exclusively through Integration Events to maintain loose coupling.EventBus Pattern
TheEventBus class (located in Shared.IntegrationEvents) orchestrates event publishing and handling:
Shared.IntegrationEvents/EventBus.cs
Integration Event Examples
Key Design Patterns
Result Pattern
All operations returnResult<T> or VoidResult to handle errors functionally:
Shared.Domain/Models/Result.cs
Aggregate Pattern
Domain entities are organized into aggregates with a single root entity that enforces invariants:- ProductAggregate: Product (root), ProductMedia, Review, Discount
- OrderAggregate: Order (root), OrderItem
- CustomerAggregate: Customer (root), CartItem, FavoriteItem
- CategoryAggregate: Category (root), ProductAttribute, ProductVariant
Repository Pattern
Data access is abstracted through repository interfaces defined in the Domain layer:Benefits of This Architecture
Maintainability
Clear separation of concerns makes code easier to understand and modify
Testability
Pure domain logic with no infrastructure dependencies
Scalability
Modules can be extracted into microservices if needed
Team Autonomy
Teams can work on different modules with minimal conflicts
Next Steps
Explore individual module documentation to understand:- Domain entities and aggregates
- Use cases and application services
- Infrastructure implementations
- API endpoints and contracts