This document outlines the architectural decisions and structure implemented for the EG-Flow solution. The structure follows modern .NET development practices with clear separation of concerns and maintainability as core principles.
No | Project Name | Description |
|---|---|---|
1 | EGU.FLOW | Empty Solution - Root container for all projects |
2 | EGU.Flow.ApiServices | Web API - Backend APIs and endpoints |
3 | EGU.Flow.AppHost | Aspire AppHost - Application orchestrator |
4 | EGU.Flow.Domain | Class Library - Domain models with zero dependencies |
5 | EGU.Flow.Core | Class Library - Shared DTOs, interfaces, and enums |
6 | EGU.Flow.Web | Blazor WebAssembly - Frontend UI application |
7 | EGU.Flow.BusinessLogic | Class Library - Business logic, services, and mappers |
Type: Empty Solution
The solution serves as the organizational unit that groups all related projects together, enabling unified build, deployment, and dependency management.
Type: ASP.NET Core Web API
This project exposes RESTful endpoints and serves as the primary interface between the frontend and business logic layers. Swagger is configured for API documentation and testing.
Key Responsibilities:
Type: .NET Aspire AppHost
The AppHost acts as the development orchestrator, coordinating multiple services. It manages service discovery, configuration, and inter-service communication during development and deployment.
Benefits:
Type: Class Library
This is an isolated layer containing pure domain models with zero external dependencies. It represents the core business entities and follows Domain-Driven Design principles.
Characteristics:
Type: Class Library
A centralized location for cross-cutting concerns and shared definitions used across multiple projects.
Contains:
Type: Blazor WebAssembly Standalone
The user interface layer built with Blazor WebAssembly, providing a rich client-side experience that runs entirely in the browser.
Characteristics:
Type: Class Library
This layer encapsulates all business rules, validation logic, and data transformations. It serves as the intermediary between the API layer and the domain layer.
Contains:
Each project has a single, well-defined responsibility. This modular approach enables independent testing and deployment, easier maintenance and debugging, team scalability, and reusability across different contexts.
The dependency direction ensures that business logic remains independent of presentation concerns, and domain models remain pure without infrastructure dependencies.
Web → ApiServices → BusinessLogic → Domain (with Core shared across layers)
Choosing .NET 9 provides latest performance improvements, modern C# language features, enhanced security updates, and long-term support.
A comprehensive .gitignore file at the solution root handles Visual Studio artifacts, user-specific files, Copilot and IDE-generated files, and build outputs. This ensures a clean repository with only source code tracked.
Swagger/OpenAPI is configured in the ApiServices project to provide interactive API documentation, built-in testing capabilities, client code generation support, and clear API contract definition.