Amirehsan Kohannasab

An appointment booking platform for a medical clinic, built as a three-project ASP.NET Core MVC solution with a swappable persistence layer.

Architecture

Separated into Clinic.Mvc (presentation), Clinic.Application (use cases and services) and Clinic.Data (EF Core context, entities and migrations). Dependencies point inward only, so the data provider can change without touching business logic. Central Package Management keeps NuGet versions defined in one place across all projects.

Engineering challenge

The system targets SQL Server, which made it impossible to run or test on a machine without LocalDB installed. I abstracted the provider behind configuration so the same build runs on SQLite from two environment variables, then scripted the full cycle — drop database, build, boot, run an end-to-end HTTP suite, shut down — into a single command. Contributors can now verify the app with no database server installed at all.

• C#
• ASP.NET Core MVC
• EF Core
• SQL Server
• SQLite
• PowerShell

A production-shaped .NET solution template that encodes clean architecture boundaries, containerisation and CI as defaults rather than as later additions.

Architecture

Five projects under src/: Domain (entities and invariants), Application (use cases), Infrastructure (persistence and external services), SharedKernel (cross-cutting primitives) and Web.Api (transport). The dependency rule is enforced structurally — Domain references nothing, and Web.Api is the only project that knows about HTTP.

Engineering challenge

Architectural rules decay when they rely on discipline alone. I moved them into the build instead: TreatWarningsAsErrors with AnalysisMode=All plus SonarAnalyzer promotes code-quality regressions to build failures, Central Package Management removes version drift between projects, and Docker Compose with a GitHub Actions workflow makes a clean checkout runnable and verified without local setup.

• C#
• ASP.NET Core
• EF Core
• Docker Compose
• GitHub Actions
• SonarAnalyzer

A live messaging application using SignalR for bidirectional transport, built on the same clean architecture layering as the template above.

Architecture

SignalR hubs sit in the transport layer and delegate straight to application services, so message handling logic stays independent of the connection mechanism and remains unit-testable without a live socket. Runs under Docker Compose alongside its database.

Engineering challenge

Real-time transport tends to pull business logic into the hub, where it can only be exercised through a live connection. Keeping the hub as a thin adapter over application services meant the messaging rules could be tested directly, and the same services are reusable if the transport is later swapped for WebSockets or gRPC streaming.

• C#
• ASP.NET Core
• SignalR
• EF Core
• Docker Compose

An ASP.NET Core storefront with a shopping cart and a full administrative back office, organised with an onion-architecture layout.

Architecture

Split across Domain, Application, Infra.Data, IOC and Web. The IOC project centralises dependency registration so composition lives in one place instead of being scattered through the web layer — which keeps the Web project free of any direct reference to the data layer.

Engineering challenge

Cart state has to survive both anonymous browsing and sign-in without losing items at the moment of authentication. Modelling the cart as a domain concept rather than as session data made that transition explicit, and kept order totals computed in one place instead of recalculated per view.

• C#
• ASP.NET Core MVC
• EF Core
• SQL Server
• JavaScript