darxx03eh/inventorymanagementsystem

1. Overall shape

- This is a small layered console application with a clear separation between presentation, business rules, and storage.

- The solution is split into four project boundaries: Models, Infrastructure, Service, and UI, with Program.cs acting as the composition root.

2. Entry point and composition

- Program.cs is the top-level executable entry point.

- It likely wires together the repository, service, and UI objects, then starts the menu loop.

- The README notes global error handling lives here, so fatal exceptions are caught before the process exits.

3. Domain model

- InventoryManagementSystem.Models/Entities/Product.cs is the core data contract.

- Product is the shared entity passed through the layers, carrying the inventory state such as name, price, and quantity.

4. Storage boundary: Infrastructure

- InventoryManagementSystem.Infrastructure owns product persistence concerns.

- IProductRepository defines the storage abstraction, while ProductRepository is the concrete implementation.

- Current storage is in-memory, so this layer is not a database adapter yet; it is the isolated place where persistent storage could be swapped in later.

5. Business logic boundary: Service

- InventoryManagementSystem.Service contains the inventory use-case rules in InventoryService.

- IInventoryService abstracts the operations the UI consumes: adding, editing, deleting, searching, and listing products.

- Validation rules described in the README belong here conceptually, not in the UI or repository.

6. Presentation boundary: UI

- InventoryManagementSystem.UI owns the console experience and user interaction flow.

- Menu implements the main navigation loop and user actions through IMenu.

- ConsoleHelper centralizes console formatting and prompts, keeping presentation details out of the service layer.

7. User interaction flow

- The user interacts only with the UI layer.

- UI collects input, calls the service layer, and renders results or validation messages.

- Service calls the repository to read or mutate the in-memory product collection.

8. Key data flow

- The main path is: console input → UI menu → service validation/business rules → repository storage → service result → UI rendering.

- Reads follow the same path in reverse: UI asks service for product data, service fetches from repository, then UI displays tables, summaries, or confirmations.

9. Error handling

- Expected validation failures are handled as part of the normal UI experience and shown in styled error panels.

- Unexpected failures bubble to Program.cs, where they are converted into a fatal error screen and a non-zero exit code.

- That means the architecture separates recoverable business errors from unrecoverable application errors.

10. External library and runtime

- The main non-BCL dependency called out in the README is Spectre.Console, which shapes the UI layer with banners, panels, tables, charts, prompts, and loading animations.

- The target runtime is .NET 10, and the project is built as a console application rather than a web or desktop app.

11. What to draw in an architecture diagram

- Show Program.cs at the top as the composition root.

- Under it, show three horizontal layers: UI on top, Service in the middle, Infrastructure at the bottom, with Models shared across them.

- Draw one-way dependencies downward: UI depends on Service, Service depends on repository abstractions and models, Infrastructure implements repository storage, and Models remain dependency-free.

12. Current architectural constraint

- The system is intentionally ephemeral: inventory data disappears when the process exits.

- That makes the repository layer the main seam for future persistence work, such as file storage or a database, without changing the UI flow.