Skip to main content

Build & Run

What is Eos?​

Eos is the product/family name for the greenfield platform replacing the legacy Logiswift system — not a single app. Each piece underneath it is named by function: Eos.Api (backend API), Eos.Workers (background jobs), and — coming next — Eos.Web (Operations frontend), Eos.Rf, Eos.Reporting, and Eos.Contracts (shared DTOs consumed by the frontends).

Stack​

  • .NET 10, C#, nullable reference types and implicit usings enabled.
  • ASP.NET Core Web API as the single API host.
  • SQL Server with EF Core 10, database-first (scaffolded from the existing schema).
  • .NET Worker Service for background jobs (replaces the old Windows Services).
  • xUnit + FluentAssertions + NSubstitute for tests; FluentValidation for validation.

Repository layout — monorepo, one solution per area​

This is a monorepo: one Git repo, multiple areas, each with its own solution and its own CI/CD pipeline — they are not built or deployed together.

/                       shared conventions only: CLAUDE.md, README.md,
                        Directory.Build.props, .editorconfig, .gitattributes, .gitignore
/backend/               Logiswift.Eos.slnx — everything this document describes
  src/Logiswift.Eos.Api/
  src/Logiswift.Eos.Application/
  src/Logiswift.Eos.Domain/
  src/Logiswift.Eos.Infrastructure/
  src/Logiswift.Eos.Workers/
  tests/...
/frontend/              the frontend area, own tooling/pipeline (not a .NET solution)
  src/eos-web/           React + Vite + TypeScript, Operations frontend
  src/eos-rf/            (coming next) handheld-scanner frontend
  src/eos-reporting/     (coming next) reporting frontend
/eos-contracts/         (coming next) shared DTOs consumed by the frontends, own solution
note

Two folders shown above are new since this documentation site was built: /docs/ (this Docusaurus site itself, sibling to backend//frontend/) and /docs-internal/ (internal planning docs).

Existing project namespaces (Logiswift.Eos.Api, Logiswift.Eos.Application, Logiswift.Eos.Domain, Logiswift.Eos.Infrastructure, Logiswift.Eos.Workers) are already correctly component-named — never rename them for this layout; the restructuring is folders and docs only, not namespaces.

Build & run​

All commands below run from backend/ (this area's own root):

cd backend
dotnet restore
dotnet build
dotnet test
dotnet run --project src/Logiswift.Eos.Api      # API + Swagger at /swagger
dotnet run --project src/Logiswift.Eos.Workers  # background jobs

Multi-client deployment​

Each client (CPL, AFF, AXENDO, CEVA, CJ, DENMAR, deugro, IMISK, LEOCH, LDC, LOGISWIFT, PERFORMANS, BARRICK, PBCU, QUANTA) gets its own deployment of the Api + Workers, each pointed at that client's database via the EosDb connection string in configuration. Do not bake client-specific logic into code; drive differences through configuration.

Conventions​

  • async/await everywhere for I/O; pass CancellationToken through.
  • DTOs at the API boundary — never expose EF entities over the wire.
  • Constructor injection via the built-in DI container.
  • One job class per former Windows Service under Workers/Jobs, each a BackgroundService.
  • Tests: service/use-case logic in *.Application.Tests, domain logic in *.Domain.Tests, DB-touching tests in *.Integration.Tests.

:::danger Do not

  • Do not apply EF migrations or run dotnet ef database update against any real database without explicit confirmation.
  • Do not hand-edit scaffolded files.
  • Do not add cross-module dependencies that bypass Application interfaces.
  • Do not introduce microservice splits without a discussion first.
  • Do not cache transactional data (Operations/Rf/Reporting/Edi entities). In-memory caching is reserved for Mas* lookup/reference tables only. :::