habibor-rahaman1010/asp-net-batch-10

1. Overall shape

This is a layered ASP.NET Core solution built around an inventory domain. The solution is split into four main runtime projects: a web UI, an application-services layer, a domain model, and an infrastructure layer, plus a separate worker service and a test project.

2. Presentation boundary: DevSkill.Inventory.Web

The web project is the user-facing host. It uses ASP.NET Core MVC with Areas, especially an Admin area for inventory maintenance screens. It contains controllers, Razor views, partials, view models, and static assets from AdminLTE/Bootstrap/jQuery. This is the primary entry point for human users.

3. Web module responsibilities

The web layer owns request handling, form/view models, AutoMapper profiles, and UI composition. Controllers such as ProductController, CategoryController, BrandController, StockAdjustmentController, and DashboardController map user actions to application services. AccountController handles authentication-related flows like login, registration, and email confirmation.

4. Application layer: orchestration and business use cases

DevSkill.Inventory.Application contains the management services for each business capability: products, categories, subcategories, brands, units, taxes, locations, warranties, product types, barcode types, adjustment types, and stock adjustments. These services are the main orchestration boundary between UI and persistence and are exposed through matching service contracts.

5. Domain model: core business concepts

DevSkill.Inventory.Domain defines the inventory language of the system: entities such as Product, Brand, Category, StockAdjustment, BusinessLocation, Unit, Warranty, and tax-related types. It also holds DTOs for product search/listing, enums like ProductStatus and AllowDecimal, and shared abstractions such as repository contracts, unit-of-work contracts, and utility interfaces.

6. Infrastructure layer: persistence and concrete services

DevSkill.Inventory.Infrastructure provides the implementations for domain abstractions. It includes repository classes, unit-of-work implementations, EF Core DbContexts, application time abstraction, email utility, SQL utility, Razor utility, TempData helpers, and the concrete inventory identity classes. This is the bridge from the pure domain/application layers to actual runtime dependencies.

7. Data storage boundary

There are two distinct database contexts: ApplicationDbContext for identity/authentication data and InventoryDbContext for inventory business data. The web project carries EF Core migrations for both contexts, indicating that the web host is responsible for creating and evolving the databases during deployment.

8. Identity and authorization

Authentication is implemented with custom ASP.NET Core Identity types in the infrastructure project: users, roles, claims, logins, tokens, managers, and a custom AgeRequirement. This suggests authorization is not just role-based; it also includes policy/requirement-based access control. The account views and admin user-management screens depend on this identity subsystem.

9. Inventory feature flow

The common flow for business features is: browser request → MVC controller/view model → application management service → repository/unit-of-work abstraction → EF Core context → database. The admin screens are CRUD-heavy and centered on catalog/master-data management, with stock adjustment and product maintenance as the more transaction-oriented parts of the domain.

10. Worker process

DevSkill.Inventory.WorkerService is a separate .NET worker host with its own Program, Worker, and module registration. The tree does not show what jobs it runs, but architecturally it is a background execution boundary separate from the web UI, likely intended for scheduled or asynchronous processing using the same solution conventions.

11. Cross-cutting concerns

Email sending, current time abstraction, SQL helpers, and TempData helpers are separated into reusable services rather than being embedded in controllers. This indicates an attempt to keep business/application logic testable and to isolate external concerns from the domain.

12. Testing strategy

The test project focuses on application-service tests for products, categories, brands, business locations, product types, and stock adjustments. That implies the critical logic is expected to live in the application layer, with tests validating orchestration and business rules there rather than in the web layer.