Skip to content

Solution layout

What it is

The ManpowerIQ solution is organised into the four Clean Architecture projects plus the two client apps. This page is the map: which project holds what, and which way the dependencies point.

Why it's built this way

The projects are split so that the business core does not depend on the database or the web framework. Domain and Application carry the rules; Infrastructure and API carry the wiring. That direction (everything points inward toward the domain) is what makes the allocation engine, demand rules, and entities testable without Postgres or HTTP. The dependency rule is covered in detail in Clean Architecture.

How it works

flowchart LR
    API[ManpowerIQ.API<br/>ASP.NET Core] --> APP[ManpowerIQ.Application]
    INFRA[ManpowerIQ.Infrastructure<br/>EF Core, Hangfire, Auth] --> APP
    API --> INFRA
    APP --> DOM[ManpowerIQ.Domain]
    INFRA --> DOM
    WEB[web/ · React + Vite] -.HTTP/JWT.-> API
    MOB[mobile/ · Expo skeleton] -.HTTP.-> API

Backend (manpoweriq/src/)

Project Responsibility Representative contents
ManpowerIQ.Domain Entities, enums, the rules' shapes — no framework dependencies. Domain/Common/AuditableEntity.cs, TenantEntity.cs; Domain/Entities/* (Employee, Role, Permission, AuditEvent…) (sheet 01 §entities)
ManpowerIQ.Application Business services and interfaces — the use cases. allocation engine, demand planning, leave, attendance services; Application/Auditing/IAuditLogger.cs, Application/Tenancy/ICurrentTenantProvider.cs, Application/Resources/ErrorMessages.resx
ManpowerIQ.Infrastructure EF Core implementation, interceptors, auth, Hangfire, imports. Persistence/ManpowerIQDbContext.cs, Persistence/Interceptors/TenantStampingInterceptor.cs, Tenancy/CurrentTenantProvider.cs, Auth/JwtTokenMinter.cs, Services/ImportJobRunner.cs
ManpowerIQ.API ASP.NET Core host: controllers, middleware, DI, the request pipeline. Program.cs (DI + middleware order), Controllers/*, Middleware/TenantContextMiddleware.cs

Clients (manpoweriq/)

  • web/ — the React + Vite SPA. The real product surface; responsive Tailwind, JWT auth.
  • mobile/ — an Expo + React Native + TypeScript project that is a single health-check screen (mobile/App.tsx), not a functional app (sheet 20 §build-status).

Teststests/ManpowerIQ.E2E.Tests/ (Playwright E2E + the demo-data seeder) and the unit/integration test projects.

Gotchas / constraints

  • Infrastructure depends on Application, not the reverse. Application defines interfaces (ICurrentTenantProvider, IAuditLogger); Infrastructure implements them. Don't add an Application→Infrastructure reference (see Clean Architecture).
  • mobile/ bulk is dependency weight, not features. mobile/node_modules is large, but the app code is App.tsx + index.ts only (sheet 20). Don't mistake it for a built mobile app.
  • web/ and mobile/ share no code — separate codebases (DOM+Tailwind vs React Native primitives) (sheet 20).
  • The repo is not under git in the verification environment, so sources are cited by file.cs:line against the EF model snapshot, not a commit hash (sheet 00-index).

Build status

Available — the four-project backend and the React web app are the live solution. The mobile project is Planned/skeleton (sheet 20).