Platform Evolution
Assessment run-2026-07-27-1 · 213 of 213 repos assessed
Repos / commission-statements-api

commission-statements-api

ASP.NET Core 8 read-side API of the MonthlyCommissions system, serving commission statements, remittances, payment history and dashboard summaries from MongoDB to the frontend client and generating statement/remittance PDFs.

91 · greenlowlooseAWSZDD: no excuseapi

Health score

91

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.


Runtime currency / 25
25
Runs on supported modern .NET
Legacy transport / 15
15
No legacy WCF or SOAP surface
Test posture / 15
8
Some tests, coverage is thin
Security hygiene / 15
15
No credentials found in source
Dangerous coupling / 15
15
No dangerous coupling detected
Activity / 10
8
Last commit six to twelve months ago
Deployment hygiene / 5
5
CI in place
Health over time
2026-07-27 (run-2026-07-27-1): 91
Baseline 91 recorded 2026-07-27. The trend fills in with each monthly assessment run.

Facts

Languagescsharp
FrameworksASP.NET Core 8, MongoDB.Driver 3, Swashbuckle
Runtimes.NET 8
Tests / CIsome / CI in place
Last commit2025-12-22
OwnerOwner unknown (mapping to be curated)
DomainPayments and finance (system generated; curate in repo-owners.json to override)
Product areaShared platform
HostedAWS Deployed to AWS
  • build "commission-statements-api" (azure-pipelines.yml): AWS signal "useTFVarsDeployment: true"
Releases0 release pipeline(s):
Integrationrest, jwt
SourceOpen in Azure DevOps

Risk flags

No risk flags recorded.

Each flag links to its glossary definition.

Dependencies in context

Laying out the graph…
greenamberreddata store (square, dashed link)Node size follows fan-in. Click any node to open it.

Entanglement

loose No binding mechanisms apply: this system needs no untangling work.

    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 excuse

    Nothing 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. Separating it from the three-week release is a process decision, not a technical one.

    Dependencies and gotchas
    • 1 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
    Steps
    1. Adopt the four-stage discipline from the ZDD engineering standard: pre-deployment compatibility, deployment, feature activation behind a flag, post-release cleanup.
    2. Raise automated test coverage first: ZDD trades the end-of-sprint manual gate for continuous automated confidence, so the tests are the entry ticket.
    3. 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.
    4. Audit serialized data: anything in Redis, queues or shared caches must deserialize cleanly across adjacent versions.
    5. Wrap behaviour changes in feature flags so code deploys dark and release becomes a business decision, not a deployment event.
    6. Use ECS rolling deployments with health checks gating traffic, and take this service off the three-week release train.
    7. 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 applicable

    No SQL Server dependency is recorded for this repo. Nothing to migrate.

    Containerisation

    Already containerised

    Its pipelines already build containers and deploy to AWS. Nothing to do here.

    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

    commission-statements-api

    Purpose

    The read-only half of MonthlyCommissions (writes are handled by a separate commission service): controllers for commission statements, remittances, payment history, retrospective commissions, outstanding deductions and a dashboard summary, all served from a MongoDB store, plus PDF generation for statements and remittances via the DocumentationBuilder client. Built for the frontend client and deployed on AWS ECS.

    Tech stack

    C# 12 on .NET 8 (API, Common, DataAccess and DataContract projects plus one test project). Phenix.Auth.JWTBearer/PhenixAuth with TC.Cognito.Auth.Client (Cognito JWT with user context), MongoDB.Driver 3.5 through TC.ConnectionBroker.Mongo, Swashbuckle 9 (non-production only), TC.Diagnostics health checks, WebApi.Logger, StyleCop/Sonar/SecurityCodeScan analyzers and Nerdbank.GitVersioning.

    Deployment

    No classic release pipelines (release_count 0); traced via build->yaml-deploy with build pipeline commission-statements-api. Two YAML pipelines against the shared InternalOSS/azure-pipelines-templates ci.yml: azure-pipelines.yml container-builds TC.CommissionStatements.API (.NET 8 SDK, containerAfterBuild, useTFVarsDeployment, functional area/namespace phenix, eu-west-1) for ECS, and build.yaml packs TC.CommissionStatements.DataContract as a NuGet package for consumers. Per-environment appsettings for qa/preproduction/production (production file is empty — everything comes from ConnectionBroker/environment).

    Dependencies

    Internal packages: TC.ConnectionBroker.* 1.19 (tc-connectionbroker), TC.Diagnostics.HealthChecks.AspNetCoreExtensions (tc-diagnostics-portal), TC.DocumentationBuilder.Client + TC.DocumentationBuilder.TCMonthlyCommissions.Contracts (backoffice-documentation-booking) for PDFs, TC.Phenix.CompanyInfo (company-info-api). Phenix.Auth.JWTBearer, PhenixAuth, TC.Cognito.Auth.Client and WebApi.Logger map to no included repo. External: AWS Cognito for JWT auth.

    Data stores

    Reads the TCCommissionStatements MongoDB database (CommissionStatements, CommissionPaymentHistory, CommissionSummary, Remittances, UnconfirmedRetrospectiveCommission, OutstandingDeduction collections) via ConnectionBroker Mongo. Read-only by design; the write side is owned elsewhere.

    Integration points

    Inbound REST with Cognito/Phenix JWT bearer auth; outbound REST to the DocumentationBuilder service for PDF rendering. No WCF, buses or SQL.

    Code health

    One xUnit test project with a handful of unit tests (money, date and retro-commission logic — no controller/repository coverage). A real, maintained README with an explicit TODO list (parameter validation, caching, finish README). Rough edges in code: CompanyInfoService hard-codes per-company currency/culture values ("fetch from a service when we have it on AWS") and a commented-out, admittedly non-working Mongo health check. Last commit 2025-12-22.

    Modernisation risks

    Low — modern .NET 8, containerised AWS deployment, YAML CI. Residual concerns: thin test coverage for an API that renders financial statements, hard-coded company reference data that must be kept in sync manually until a proper company-info source exists on AWS, and the split read/write architecture meaning correctness depends on whatever populates the MongoDB store.