almamun09/localscout_v2

1. Overall shape

LocalScout is a .NET 8 ASP.NET Core MVC solution split into three clear layers: Domain, Application, and Infrastructure, with Web as the presentation host. The runtime entrypoint is LocalScout.Web, which wires together Identity, repositories, services, and MVC controllers/views.

2. Domain layer: core business model

LocalScout.Domain contains the business entities and enums that define the system’s state: users, services, service categories, bookings, reviews, notifications, audit logs, verification requests, provider time slots, service blocks, and reschedule proposals. These are the canonical data objects the rest of the app revolves around.

3. Application layer: contracts and screen-shaped DTOs

LocalScout.Application is mostly a contract and mapping layer. It defines repository/service interfaces plus DTOs for bookings, payments, reports, reviews, dashboards, notifications, verification, and search. This layer shapes data for specific use cases instead of exposing raw domain entities to the UI.

4. Infrastructure layer: persistence and external integrations

LocalScout.Infrastructure owns EF Core persistence through ApplicationDbContext, entity configurations, migrations, and seeding. It also implements the repository interfaces and domain services such as scheduling, time zone handling, email, PDF receipt/report generation, AI description generation, and SSLCommerz payment integration.

5. Presentation layer: MVC site and Identity UI

LocalScout.Web hosts the app’s controllers, Razor views, and Identity pages. The UI is organized by functional areas like Home, Service, Booking, Payment, Review, Report, Admin, Provider, and User, plus the built-in Areas/Identity registration/login flow. The app uses standard MVC request/response boundaries rather than APIs as the primary interface.

6. Authentication and roles

ASP.NET Core Identity is central to the architecture. The system supports role-based access control with Admin, ServiceProvider, and User, and the registration flow is split for normal users and providers. Identity pages under Areas/Identity handle confirmation, password reset, login/logout, and provider-specific registration.

7. Service marketplace flow

The main user journey is: browse/search services, view service details, create bookings, and track booking status. Controllers in Service, Booking, and Home assemble DTOs for cards, detail pages, and search results, while the repository layer persists service listings, provider relationships, and availability data.

8. Booking, rescheduling, and payments

Booking is a multi-stage workflow with provider acceptance/decline, proposed time adjustments, cancellation, and completion. Payment is separated into its own module and uses SSLCommerz plus receipt/history DTOs. This gives the architecture a distinct transaction boundary: booking state changes happen in the app, but payment processing crosses into an external gateway and then back into persisted history/receipt records.

9. Provider verification and category governance

Providers submit verification documents and category requests, which are then reviewed by admins. The repo includes verification entities, category request handling, and service category approval/inactive/active management. Uploaded verification PDFs are stored under wwwroot/uploads, making document handling part of the system boundary rather than pure database data.

10. Operational concerns: notifications, audit, reports

Notifications are a first-class subsystem with in-app read/unread state. Audit logging tracks administrative and security-relevant actions. Reporting is split by audience: admin, provider, and user reports, with PDF generation handled in infrastructure. These are not just UI pages; they represent distinct read-model style views over the same transactional data.

11. Location and AI integrations

Location features are split across a web-side JavaScript module and an infrastructure LocationService. The frontend handles geolocation/autocomplete behavior, while the backend integrates with LocationIQ for geocoding and proximity support. AI-assisted content generation is similarly separated behind IAIService and an implementation in infrastructure, using Hugging Face for generated descriptions.

12. Front-end assets and static content

The web project carries substantial static UI assets: AdminLTE, Bootstrap, jQuery, DataTables, Select2, SweetAlert2, and custom JS modules for validation, notifications, multi-step forms, and location services. This means the presentation layer is not a thin shell; a significant amount of user interaction logic lives in browser-side scripts and Razor partials.

13. Persistence boundary and migrations

All durable state is backed by SQL Server through EF Core migrations in LocalScout.Infrastructure/Migrations. The migration history shows the app evolving around booking, payment info, verification, notifications, audit logs, and service/category changes. DbSeeder and the role constants indicate the database is also responsible for bootstrapping platform roles and initial data.

14. How to diagram the main dependency direction

The clean dependency direction is: browser/UI → MVC controllers/Razor pages → application DTOs and interfaces → infrastructure implementations → EF Core/SQL Server and external services. Domain stays isolated at the center, while the web project is the composition root and the infrastructure project is where side effects live.