service-fee-api
ASP.NET Core 8 API standardising service fees for corporate (business travel) accounts, storing fee configuration and business settings in MongoDB.
Health score
0 to 100 across seven weighted factors; nothing is hidden. Green is 75 and above, amber 50 to 74, red below 50. How scoring works.
Facts
| Languages | csharp |
| Frameworks | ASP.NET Core 8, MediatR, FluentValidation, Serilog |
| Runtimes | .NET 8 |
| Tests / CI | good / CI in place |
| Last commit | 2026-05-12 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Selling and quoting (system generated; curate in repo-owners.json to override) |
| Product area | Phenix |
| Hosted | AWS + on-prem Ships artefacts to both AWS and on-prem machines (see evidence below)
|
| Releases | 2 release pipeline(s): \finance\service-fee\service-fee-api on-prem; \finance\service-fee\service-fee-api on-prem Stealth |
| Integration | rest, jwt |
| Source | Open in Azure DevOps |
Risk flags
No risk flags recorded.
Each flag links to its glossary definition.
Dependencies in context
Entanglement
loosely attached Bound into the core by 1 mechanism(s).
- Pinning dependency: phenix-feature-service
Detaches when its pinning dependencies are cut or multi-targeted (phenix-feature-service).
Migration playbooks
Generated from this repo's assessment data: what is feasible, what blocks it, and the steps in order. Ratings: green means actionable now, amber means sequence other work first, red means blocked, grey means not applicable.
ZDD adoption
No excuseNothing technical is holding this repo on the three-week release. It either already deploys without downtime (AWS) or is a modern, well-tested service the automated stealth path can carry today. Already deploys as a container to AWS, which releases without downtime today. Some artefacts still deploy on-prem; they follow the on-prem path. Separating it from the three-week release is a process decision, not a technical one.
- 3 system(s) depend on this repo; during a rolling deploy they will talk to old and new versions at once, so responses must stay compatible
- Feature flags come from phenix-feature-service (WCF-only): flag reads themselves are a legacy dependency to watch
- Adopt the four-stage discipline from the ZDD engineering standard: pre-deployment compatibility, deployment, feature activation behind a flag, post-release cleanup.
- Make every change dual-version safe: backwards-compatible APIs (new major version for breaking wire changes), expand and contract for any schema change, and consumers tolerant of unknown fields.
- Audit serialized data: anything in Redis, queues or shared caches must deserialize cleanly across adjacent versions.
- Wrap behaviour changes in feature flags so code deploys dark and release becomes a business decision, not a deployment event.
- Route deployments through the Workflow Engine's automated drain, deploy, health-check, return cycle (the path proven by the first automated production run in mid-2026).
- Verify with area-scoped regression rather than the whole-platform cycle, and watch error rates after rollout with automated rollback on alert.
SQL Server exit
Not applicableNo SQL Server dependency is recorded for this repo. Nothing to migrate.
Containerisation
Partially containerisedPart of this repo already builds containers for AWS while other artefacts still deploy to on-prem machines. Finish the job by moving the remaining artefacts (see the hosting evidence on this page) through the same pipeline template.
- Identify the artefacts still deploying through deployment-group release pipelines (listed in the hosting evidence).
- Move each to the shared ci.yml pipeline template with the container parameters, as the already-containerised artefacts in this repo do.
- Disarm the old release pipelines once traffic is confirmed on the new deployment.
Recommended actions
No specific actions for this repo. It either needs only normal maintenance, or its work is covered by an estate-level action. See the full programme.
Assessment notes
service-fee-api
Purpose
Standardises handling of service fees for corporate accounts (consistency, visibility, RPI adherence). Controllers cover service fees, default service fees, business settings and request logs; the Application layer is MediatR command/query handlers with FluentValidation. Two NuGet client packages are published — a generated TC.ServiceFee.Api.Client (NSwag from the OpenAPI spec) and a BackOfficeClient wrapper — so other estate apps consume the API without hand-rolled HTTP.
Tech stack
C# .NET 8 across six SDK-style projects (API, Application, DataAccess, Common, two client libraries; clients also target netstandard2.0). MongoDB.Driver 3.5 with TC.ScriptRunner.Mongo change scripts for schema/data migrations, Phenix.Auth.JWTBearer authentication, Serilog, Asp.Versioning, Swashbuckle/NSwag, StyleCop and Nerdbank.GitVersioning.
Deployment
Included as prod_application with 2 releases from build pipeline service-fee-api on-prem, via \finance\service-fee\service-fee-api on-prem and its Stealth variant. Notably the repo carries two pipeline YAMLs: azure-pipelines.yml builds a container for AWS (containerNamespace: phenix), while build.yaml builds the solution and publishes the client packages — production currently tracks the on-prem path.
Dependencies
Internal packages: TC.ConnectionBroker.* including the Mongo broker (tc-connectionbroker), TC.Phenix.Feature (phenix-feature-service), plus TC.Phenix.CompanyInfo and TC.Phenix.Services.Client (booking service reference types; hosting repo not confidently identified). No external third-party services.
Data stores
MongoDB: owns the ServiceFee database (business service fees, business settings, request logs collections) and reads the Destinations database. No SQL Server.
Integration points
Inbound versioned REST secured with Phenix JWT bearer auth; MongoDB via ConnectionBroker. No message bus or WCF hosting.
Code health
Good: three test projects (API tests, application tests, client integration tests with a fake connection broker and API driver) across 44 test files, a real README with architecture diagram, and modern dependencies throughout. Last commit 2026-05-12.
Modernisation risks
Low — this is one of the healthier repos in the estate. The only threads to watch: the on-prem/container dual pipeline suggests an unfinished move to AWS containers, and it embeds booking-service WCF reference types via TC.Phenix.Services.Client in its data-access change scripts, a small legacy coupling.