Vine2Wine

Application web de gestion du travail pour les vignerons.

Stack

Couche	Technologie
Backend	C# / .NET 10, ASP.NET Core
ORM	Entity Framework Core 10
BDD	PostgreSQL 18
Architecture	DDD + CQRS (dispatcher custom)
Frontend	Angular 22

Structure du monorepo

vine2wine/
├── backend/
│   ├── Vine2Wine.sln
│   └── src/
│       ├── Vine2Wine.Domain/          # Agrégats, events, value objects
│       ├── Vine2Wine.Application/     # Use cases (Catalog, WorkPlanning), ISender
│       ├── Vine2Wine.Infrastructure/  # EF Core, repositories, persistence
│       └── Vine2Wine.Api/             # Controllers REST
├── frontend/                          # Application Angular
└── docker-compose.yml                 # PostgreSQL

Prérequis

• .NET 10 SDK
• Node.js 20+
• Docker (pour PostgreSQL)

Démarrage

1. Base de données

docker compose up -d

2. Backend

cd backend
dotnet restore
dotnet run --project src/Vine2Wine.Api

API disponible sur http://localhost:5000 (OpenAPI : http://localhost:5000/openapi/v1.json)

3. Frontend

cd frontend
npm install
npm start

Application disponible sur http://localhost:4200

Architecture DDD / CQRS

Controller REST
    │
    ├── Command ──► ISender ──► CommandHandler ──► Agrégat (méthodes métier)
    │                                                  │
    │                                                  ▼
    │                                             Domain Events
    │                                                  │
    │                                                  ▼
    │                                      Persistence (EF Core)
    │                                                  │
    │                                                  ▼
    │                                      Event Dispatcher (effets de bord)
    │
    └── Query ──► ISender ──► QueryHandler ──► Read Repository (lecture directe BDD)

Les commands modifient l'état via les agrégats. Les queries lisent directement la BDD sans passer par le domaine.

L'Application est organisée par capacité / use case (Catalog/, WorkPlanning/), pas par agrégat : un dossier = un cas d'usage (command ou query + handler).

Le bus CQRS est une implémentation custom (ISender / Sender) — pas de MediatR.

Les domain events ne sont pas persistés : ils déclenchent la sauvegarde de l'état courant de l'agrégat, puis des effets de bord (logs, notifications, projections).

Exemple d'agrégat

Work (fait réalisé) et WorkOrder (préparation, Épic 5) illustrent le pattern :

• Work.RecordPhytosanitary(...) / RecordNonPhytosanitary(...) → fait registre (WorkRecorded)
• WorkOrder.Plan… → intent planifié ; Complete(workId) / Cancel() → cycle de vie ordre
• Le handler persiste l'agrégat puis dispatch les events