Edukacyjny projekt MVP systemu dla wielomarkowej kuchni typu dark kitchen. Repozytorium służy do ćwiczenia architektury mikroserwisowej, komunikacji zdarzeniowej, testów integracyjnych z .NET Aspire oraz frontendów operacyjnych dla kuchni, pakowania i sprzedaży.

Projekt jest na wczesnym etapie: obecnie zawiera fundament solution, AppHost Aspire, szkielety usług API, aplikacje React/Vite oraz skonfigurowane warstwy testów. Logika domenowa będzie rozwijana zgodnie z roadmapą w docs.

System obsługuje scenariusz dark kitchen, w którym jedna fizyczna kuchnia prowadzi wiele marek jedzeniowych i przyjmuje zamówienia z własnego storefrontu oraz kanałów delivery.

Docelowy przepływ:

Storefront / Mock Delivery
        |
        v
Order Management Service
        |
        v
Inventory Service -> Catalog & Recipe Service
        |
        v
Kitchen Display System
        |
        v
Packing Service

Najważniejsze obszary:

• katalog marek, menu, receptur i stacji kuchennych,
• składanie zamówień przez storefront i adaptery delivery,
• koordynacja zamówienia przez OMS i sagę,
• rezerwacja składników w inventory,
• obsługa przygotowania dań w KDS,
• kompletowanie zamówienia na wydawce,
• komunikacja zdarzeniowa przez RabbitMQ.

Backend:

• .NET 10, C#, ASP.NET Core Web API
• .NET Aspire AppHost i ServiceDefaults
• PostgreSQL jako baza per service
• RabbitMQ jako broker wiadomości
• Redis dla krótkotrwałego stanu i przyszłych scenariuszy realtime

Frontend:

• React 19
• TypeScript
• Vite
• osobne aplikacje dla storefrontu, panelu admina, kuchni i wydawki

Testy:

• xUnit
• Aspire.Hosting.Testing
• Playwright
• Vitest
• testy architektury i kontraktów

.
|-- docs/                         # ADR-y, opis usług, roadmapa i standardy
|-- src/
|   |-- DarkKitchen.AppHost/       # Orkiestracja lokalna przez .NET Aspire
|   |-- DarkKitchen.ServiceDefaults/
|   |-- Services/                  # Bounded contexts z projektami API i przyszłymi warstwami
|   |-- Shared/                    # Wspólne kontrakty
|   `-- Web/                       # Aplikacje React/Vite
|-- tests/
|   |-- Architecture/
|   |-- Contracts/
|   |-- Integration/
|   |-- Shared/
|   `-- e2e/                       # Testy Playwright
|-- DarkKitchen.slnx
|-- package.json
`-- playwright.config.ts

Backend API:

• DarkKitchen.Catalog.Api - marki, menu, receptury i routing do stacji kuchennych.
• DarkKitchen.Inventory.Api - stany magazynowe i rezerwacje składników.
• DarkKitchen.OrderManagement.Api - przyjmowanie zamówień, stan zamówienia i saga.
• DarkKitchen.Storefront.Api - BFF dla własnego sklepu.
• DarkKitchen.Kds.Api - backend dla kitchen display system.
• DarkKitchen.Packing.Api - kompletowanie zamówień i wydawka.

Frontend:

• admin-panel - panel administracyjny katalogu.
• storefront - sklep dla klienta.
• kitchen-app - tablet kuchenny dla stanowisk.
• packing-terminal - terminal wydawki.

• .NET SDK 10
• Node.js 24+
• npm 11+
• Docker Desktop albo inne środowisko kontenerów kompatybilne z Aspire
• przeglądarka Chromium instalowana przez Playwright dla testów E2E

Zainstaluj zależności:

dotnet restore DarkKitchen.slnx
npm install

Uruchom cały system przez Aspire:

dotnet run --project src/DarkKitchen.AppHost

AppHost uruchamia:

• mikroserwisy API,
• PostgreSQL,
• RabbitMQ z management pluginem,
• Redis,
• aplikacje frontendowe Vite,
• Aspire Dashboard.

Po starcie adres dashboardu pojawi się w konsoli.

AppHost obsługuje kilka flag konfiguracyjnych przekazywanych jako argumenty dotnet run:

• DarkKitchen:IncludeWebApps=false - uruchamia tylko backend i infrastrukturę, bez aplikacji Vite.
• DarkKitchen:UsePersistentVolumes=false - wyłącza trwałe wolumeny PostgreSQL i Redis, przydatne w testach.
• DarkKitchen:UseFixedWebPorts=true - wymusza stałe porty aplikacji webowych 5173-5176, używane przez Playwright.

Przykład:

dotnet run --project src/DarkKitchen.AppHost -- DarkKitchen:UsePersistentVolumes=false DarkKitchen:UseFixedWebPorts=true

Usługi są grupowane według bounded context:

src/Services/
|-- Catalog/
|   `-- DarkKitchen.Catalog.Api/
|-- Inventory/
|   `-- DarkKitchen.Inventory.Api/
`-- ...

Docelowo każdy kontekst może dostać własne projekty Application, Domain i Infrastructure. AppHost referencjonuje tylko projekty *.Api.csproj; projekty domenowe i infrastrukturalne nie powinny referencjonować DarkKitchen.ServiceDefaults.

Frontendy są zorganizowane jako npm workspaces. Wspólne elementy znajdują się w src/Web/packages:

• @dark-kitchen/ui - współdzielony shell UI.
• @dark-kitchen/config - konfiguracja klienta z VITE_*.
• @dark-kitchen/api-client - podstawowe narzędzia dla klientów API.

AppHost przekazuje frontendowi adres właściwego API przez VITE_API_BASE_URL. Dla produkcyjnego wdrożenia trzeba dodać osobny mechanizm serwowania zbudowanych assetów SPA, np. statyczny host, CDN albo dedykowany backend/static-file resource; Vite dev server pozostaje narzędziem lokalnym.

Frontend:

npm run dev:admin
npm run dev:storefront
npm run dev:kitchen
npm run dev:packing

Build:

dotnet build DarkKitchen.slnx
npm run build

Lint:

npm run lint

Repozytorium jest ustawione pod podejście bliższe testing trophy niż klasycznej piramidzie. Największy nacisk jest położony na testy integracyjne z Aspire, bo projekt ma uczyć pracy z prawdziwymi zależnościami: bazą, brokerem, procesami usług i frontendami.

Cały zestaw testów:

npm run test:all

Testy .NET:

dotnet test DarkKitchen.slnx

Stabilny tryb dla integracji Aspire uruchamia projekty per serwis sekwencyjnie:

npm run test:integration

Wybrane warstwy:

npm run test:architecture
npm run test:contracts
npm run test:integration
npm run test:frontend

Testy E2E:

npm run test:e2e:install
npm run test:e2e

Jeśli AppHost jest już uruchomiony na stałych portach, można pominąć krok build/start wykonywany przez skrypt główny:

npm run test:e2e:reuse

Playwright uruchamia AppHost w trybie E2E, z aplikacjami Vite na stałych portach:

• Admin Panel: http://127.0.0.1:5173
• Storefront: http://127.0.0.1:5174
• Kitchen App: http://127.0.0.1:5175
• Packing Terminal: http://127.0.0.1:5176

Raport E2E:

npm run test:e2e:report

Najważniejsze dokumenty:

• Model biznesowy dark kitchen
• Architektura
• Roadmapa zadań
• Standardy projektowe i architektoniczne
• Strategia testów
• ADR 011: Stos technologiczny

Opisy usług:

• Catalog & Recipe Service
• Inventory Service
• Order Management Service
• Storefront Service
• Kitchen Display System Service
• Packing Service

Gotowe fundamenty:

• solution .slnx,
• centralne zarządzanie pakietami NuGet,
• AppHost Aspire,
• ServiceDefaults z OpenTelemetry i health checks,
• szkielety sześciu usług API,
• cztery aplikacje React/Vite,
• projekt wspólnych kontraktów zdarzeń,
• testy architektury, kontraktowe, integracyjne i E2E.

Najbliższy etap:

• implementacja kontraktów i komunikacji zdarzeniowej,
• konfiguracja WolverineFx,
• durable inbox/outbox,
• pierwsze scenariusze domenowe dla zamówień i rezerwacji inventory.

To repozytorium ma charakter edukacyjny. Priorytetem jest czytelna architektura, dobre granice usług, testowalność i lokalne doświadczenie developerskie, a nie szybkie dostarczenie produkcyjnego systemu gastronomicznego.