ClubGear is a modular club-management platform built with ASP.NET Core MVC. It provides a core application for members, roles, permissions, self-service workflows, notifications, auditing, and administration, and it can be extended through contract-based plugins.
The project is designed as a single deployable web application rather than a microservice system. The core stays responsible for identity, data ownership, runtime hosting, and operational controls, while plugins contribute focused features through explicit contracts and extension points.
ClubGear helps clubs manage their operational data in one place:
- Member administration with list, edit, import, verification, and deletion flows.
- Membership types with configurable metadata fields and hierarchy-aware sub-member grouping.
- Member self-service so authenticated members can maintain their own profile data.
- Role and permission management backed by database-stored permissions.
- Audit and event logging for business changes and operational diagnostics.
- Email and in-app notification infrastructure, with optional external notification channels.
- External login support through configurable OpenID Connect providers.
- A plugin runtime for member-profile, general-extension, and technical plugins.
- Plugin package installation, activation, lifecycle status, compatibility checks, and signature/hash artifacts.
The following screenshots were captured from the local development profile on http://localhost:5007.
ClubGear is an ASP.NET Core 8 MVC monolith with Razor views, EF Core, SQLite, ASP.NET Core Identity, Bootstrap, and xUnit architecture tests.
At runtime, browser requests enter MVC and API controllers, flow through feature services, and persist state through EF Core. The application seeds its own schema and compatibility patches during startup instead of relying on a traditional EF migrations folder.
Browser
-> ASP.NET Core MVC and API controllers
-> Feature services and core services
-> EF Core
-> SQLite database
Plugins are hosted through a contract-first boundary. A plugin should depend on ClubGear.Plugin.Contracts and contribute features through explicit extension points instead of referencing core implementation namespaces directly.
The repository currently contains these plugin examples:
| Plugin | Category | Purpose |
|---|---|---|
CarInfo |
member-profile |
Vehicle information on member profiles and self-service pages. |
Serviceheft |
member-profile |
Service-book data that depends on the car information plugin. |
Plugin packages are distributed as ZIP files containing a manifest and the built plugin assembly. Packaging scripts can emit checksums and signature files so the host can verify installed packages.
The core member model is type-driven. Administrators can define membership types, attach metadata fields to those types, and mark selected types as containers for sub-members. The /Members overview then renders a hierarchy where a container member, such as a company, family or club, is followed by its configured sub-members.
The hierarchy is derived from MemberReference metadata values and MembershipType.AllowsSubMembers; no plugin-specific core logic or extra relationship table is required. Server-side validation prevents self-references, grandchildren and short cycles, while the member overview keeps search and type filters group-aware.
See Core Membership Hierarchy for the full design and operational notes.
| Path | Description |
|---|---|
Program.cs |
Application startup, middleware pipeline, seeding, and plugin activation. |
Controllers/ |
MVC and API controllers for account, members, admin, plugins, and self-service. |
Services/ |
Core services, authorization, notification, plugin runtime, and persistence logic. |
Models/ |
Core domain and view models. |
Views/ |
Razor views and partials. |
Contracts/Plugin/ |
Public plugin contracts used by plugin assemblies. |
plugins/ |
Plugin implementations and their manifests. |
tests/ClubGear.ArchitectureTests/ |
Architecture, plugin-boundary, and focused behavior tests. |
docs/architecture/ |
Architecture documentation and rendered diagrams. |
scripts/ |
Plugin packaging and activation-value utilities. |
For a fresh setup, start with the Quickstart.
Requirements:
- .NET SDK 8.
- SQLite, provided through EF Core SQLite packages.
- A shell capable of running the repository scripts.
Run the application:
dotnet run --launch-profile httpThe development profile serves the app at:
http://localhost:5007
Development settings live in appsettings.Development.json. By default the development database is clubmanagerv0_2.dev.db, and local email delivery uses the pickup directory configured under App_Data/MailDrop.
Run the architecture test project:
dotnet test tests/ClubGear.ArchitectureTests/ClubGear.ArchitectureTests.csprojFor targeted plugin or boundary work, prefer running the focused test classes in tests/ClubGear.ArchitectureTests/ and keep plugin-specific behavior inside plugin projects unless a core contract change is explicitly required.
ClubGear can run directly with dotnet run or as a container image. The repository includes:
Dockerfilefor a multi-stage .NET build.docker-compose.ymlfor local/container deployment.scripts/start-docker.shandscripts/start-podman.shto start the compose stack with either engine.scripts/deploy.shandscripts/build-and-export.shfor project-specific deployment workflows.
See docs/architecture/runtime-deployment.md for the detailed runtime and deployment notes.