Skip to content

Repository files navigation

MeetingFlow — Architecture Teaching Repository

Purpose

The repository contains several versions of the same domain for architecture and testing exercises. The monolith and client-server projects intentionally use database models across application boundaries. The microservices project is the refactored reference implementation with explicit HTTP contracts, public API models, mappings and a versioned integration event.

The intentionally imperfect model exposure remains in MeetingFlow.Monolith and MeetingFlow.ClientServer. It is not the design to copy into production.


Repository Structure

MeetingFlow/
├── README.md                          # This file
├── MeetingFlow.sln                      # Solution file (both .NET projects)
│
├── MeetingFlow.Monolith/                # Project 1: Server-rendered monolith
│   ├── Models/                        # EF Core entity models
│   ├── Data/                          # DbContext + seed data
│   ├── Pages/                         # Razor Pages (UI)
│   └── Program.cs
│
├── MeetingFlow.ClientServer/            # Project 2: Client-server architecture
│   ├── MeetingFlow.Api/                 # ASP.NET Core Web API
│   │   ├── Models/                    # EF Core entity models (same as monolith)
│   │   ├── Data/                      # DbContext + seed data
│   │   ├── Endpoints/                 # Minimal API endpoints + GraphQL
│   │   └── Program.cs
│   │
│   └── MeetingFlow.Web/                 # React + TypeScript + Vite frontend
│       └── src/
│           ├── types/models.ts        # TypeScript types mirroring backend entities
│           ├── api/                   # HTTP client functions
│           ├── components/            # React components
│           └── pages/                 # React pages
│
└── MeetingFlow.Microservices/           # Project 3: IDesign-style microservices
    ├── docker-compose.yml             # Postgres + 6 services
    ├── infra/postgres/init.sql        # Four schemas in one Postgres container
    ├── src/
    │   ├── Gateway/                   # Public HTTP edge (Client)
    │   ├── Managers/                  # MeetingsManager, RegistrationsManager
    │   ├── Engines/                   # SchedulingEngine (pure logic)
    │   └── Accessors/                 # DataAccessor, NotificationsAccessor
    ├── src/Contracts/                 # Service-owned HTTP and event contracts
    └── tests/                         # Testing lecture material

MeetingFlow.Monolith

A traditional ASP.NET Core monolith using Razor Pages. EF Core entity models are used directly from database queries all the way to .cshtml views. No ViewModels, no DTOs, no mapping layers.

MeetingFlow.ClientServer

A client-server architecture with:

  • MeetingFlow.Api — ASP.NET Core Web API exposing EF Core entities directly through REST endpoints and optional GraphQL (Hot Chocolate).
  • MeetingFlow.Web — React + TypeScript + Vite SPA that mirrors backend entities as TypeScript types.

MeetingFlow.Microservices

An IDesign-style microservices system running on Docker Compose with Postgres and RabbitMQ. EF Core entities remain inside their owning Resource Accessors. Services communicate through small provider-owned HTTP contracts, Managers map them into use-case models, and Gateway exposes separate public API models. Registration notifications use the versioned registration.created.v1 integration event.

See MeetingFlow.Microservices/README.md for the service graph, contract ownership rules and main flows.


How to Run

MeetingFlow.Monolith

cd MeetingFlow.Monolith
dotnet restore
dotnet run

Open http://localhost:5000 (or the URL shown in console output).

The SQLite database (meetingflow_monolith.db) is created and seeded automatically on first run.

MeetingFlow.ClientServer

Backend (API):

cd MeetingFlow.ClientServer/MeetingFlow.Api
dotnet restore
dotnet run

The API runs on http://localhost:5062 by default. GraphQL playground is available at http://localhost:5062/graphql. The SQLite database (meetingflow_api.db) is created and seeded automatically on first run.

Frontend (React):

cd MeetingFlow.ClientServer/MeetingFlow.Web
npm install
npm run dev

Open http://localhost:5173. The Vite dev server proxies /api and /graphql requests to the API.

MeetingFlow.Microservices

cd MeetingFlow.Microservices
docker compose up --build

The public gateway is available at http://localhost:8080. Postgres comes up first (with a healthcheck) and the six services start in dependency order. The schemas (meetings, registrations, feedback, notifications) are created via infra/postgres/init.sql and seeded automatically on first start.

The MeetingFlow.Microservices/tests directory is a clean starting point for the components and integration tests lecture. Exercise implementations are not included in the starter repository.


Domain Model

The domain covers meeting/conference management with these entities:

Entity Purpose
Meeting A conference or meetup with title, dates, status, venue
Session A talk or workshop within an meeting
Speaker A person giving a session
Attendee A person attending meetings
Registration Links an attendee to an meeting with ticket info
Venue Physical location hosting meetings
Feedback Attendee ratings and comments on meetings
Notification Messages sent to attendees (email, SMS, push)
AuditLogEntry System audit trail for entity changes

Tech Stack

Layer Technology
Monolith ASP.NET Core, Razor Pages, EF Core, SQLite
API ASP.NET Core, Minimal APIs, EF Core, SQLite, Hot Chocolate (GraphQL)
Frontend React, TypeScript, Vite, React Router
Microservices ASP.NET Core Minimal APIs, EF Core, Postgres, Docker Compose

About

No description, website, or topics provided.

Resources

Stars

1 star

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages