cpsu25/mamafit-server

1. MamaFit Server is a .NET 8 ASP.NET Core Web API backend for a maternity fashion platform. It is organized as a layered monolith, with the API host, business/services layer, repository layer, and shared business objects split into separate projects.

2. MamaFit.API is the HTTP entrypoint. It hosts REST controllers, middleware, Swagger/OpenAPI, CORS, JWT auth, and startup wiring. The controllers are feature-oriented rather than generic: auth, users, catalog, measurements, appointments, carts, orders, payments, shipping, warranties, chat, notifications, analytics, and AI test endpoints.

3. MamaFit.Services contains the main business logic boundary. Service classes implement orchestration for each domain area, while validators enforce request rules with FluentValidation. This is where workflows such as order processing, design requests, measurement generation, appointment handling, and notification dispatch are coordinated.

4. MamaFit.Repositories is the persistence layer. It uses a generic repository and unit-of-work pattern over Entity Framework Core, with one repository interface/implementation per aggregate. This layer isolates query and data-access logic from service rules and is the only place that should directly depend on the EF context.

5. MamaFit.BusinessObjects holds the shared domain model: EF Core ApplicationDBContext, entities, DTOs, enums, seed data, and the design-time context factory. DTOs are heavily used at service/controller boundaries, so the public API contract is defined separately from the persistence entities.

6. The core domain spans several subsystems: catalog management (Category, Style, Component, MaternityDress, Preset, AddOn), customer operations (Measurement, MeasurementDiary, Appointment), commerce (CartItem, Order, OrderItem, Transaction, Voucher*), and post-purchase flows (WarrantyRequest, WarrantyHistory, Feedback, Ticket). These are distinct business areas but share the same data store and service host.

7. Authentication and authorization are central cross-cutting concerns. The repo includes JWT token helpers, refresh tokens, OTP flows, Google login DTOs, role/user entities, and a permission middleware. This indicates the API enforces access control at the HTTP pipeline layer as well as in service logic.

8. Real-time features are handled with SignalR hubs in MamaFit.Services/Hubs. Chat and notifications are pushed through dedicated hubs, with connection management utilities to map users to active connections. The API exposes hub endpoints separately from REST controllers, but they share the same auth and user model.

9. External integrations are modeled as first-class services under MamaFit.Services/ExternalService. The backend talks to Cloudinary for images, Redis for caching, GHTK for shipping and tracking, Sepay for QR payments and webhooks, Mailgun for email, Contentful for CMS sync, and AI providers via Groq or optional Ollama. These integrations are wrapped behind service interfaces so the domain layer does not depend on provider-specific APIs directly.

10. Background processing is done with Hangfire backed by PostgreSQL storage. Recurring jobs are registered at startup and include appointment reminders and measurement generation. The architecture therefore has both request/response paths and asynchronous scheduled workflows operating on the same database state.

11. The API host also owns cross-cutting infrastructure: exception middleware, permission middleware, logging via NLog, CORS policy constants, endpoint constants, and startup service registration in ApplicationServiceExtension. These concerns shape how requests enter the system and how failures, permissions, and diagnostics are handled.

12. Deployment is container-focused. The repo includes a Dockerfile, Compose files, and a GitHub Actions pipeline that restores, builds, tests, creates the Docker image, ships compose files, and deploys to a VPS. There is also filebeat configuration for log shipping, which suggests production logs are collected outside the application container.

13. For diagramming, the main boundaries to show are: external clients calling REST or SignalR endpoints; the API host applying auth/middleware; services orchestrating validation, domain rules, caches, and integrations; repositories persisting through EF Core/PostgreSQL; and external systems such as Redis, Cloudinary, GHTK, Sepay, Mailgun, Contentful, Groq/Ollama, and Hangfire as separate dependencies.