tax-service
Sales-tax calculation for Travel Counsellors: a legacy .NET Framework WCF/SOAP service on IIS being replaced by a .NET 10 minimal REST API with its own MongoDB tax data.
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 | WCF, ASP.NET Core Minimal APIs (.NET 10), SimpleInjector |
| Runtimes | .NET Framework 4.7.2, .NET 10 |
| Tests / CI | good / CI in place |
| Last commit | 2026-07-23 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Payments and finance (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\tax-service Dev; \finance\tax-service Release |
| Integration | rest, wcf, jwt, graphql |
| Source | Open in Azure DevOps |
Dependencies in context
Entanglement
kernel Bound into the core by 2 mechanism(s).
- Pinning dependency: application-framework, phenix-feature-service
- Speaks WCF (host)
Detaches when its pinning dependencies are cut or multi-targeted (application-framework, phenix-feature-service); and when its WCF surface gains a modern interface or its WCF calls move to one.
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
A long roadTechnically eligible one day, but the blockers are structural: hosted WCF or SOAP contracts that cannot run two versions at once, or heavy legacy coupling. Sequence the modernisation work first. Hosts WCF or SOAP endpoints: strict serialization contracts cannot safely run two versions at once (the shared-enum trap). End-of-life runtime compounds the work.
- 7 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
Replatform tax-service to modern .NET
Runs on .NET Framework 4.7.2, .NET 10, out of mainstream support. Blocked until stage 2 cuts: application-framework, phenix-feature-service.
Impact: Unblocks 7 dependent system(s)
proposedAssessment notes
tax-service
Purpose
Two side-by-side solutions. TaxService.sln is the legacy WCF service (GetSalesTaxRate, IsSalesTaxRequired, Ping) that fetches tax data from the BackOffice BookingService. TaxApi.slnx is its replacement: a .NET 10 REST API owning tax zones and percentages in MongoDB, with geographic tax-location resolution via polygon matching (TC.Geo.TaxLib) and richer tax breakdown responses. Client NuGet packages (Api.Client, ApiToggle, RetailBookingIntegration, ServiceContract) let consumers switch between old and new implementations.
Tech stack
Legacy side: C# .NET Framework 4.7.2 WCF hosted in IIS with SimpleInjector. Modern side: .NET 10 minimal APIs with source-generated JSON, Phenix.Auth.JWTBearer 2.x, MongoDB.Driver 3.10 with TC.ScriptRunner.Mongo change scripts, health checks, and a benchmark suite. Shared libraries multi-target from net462 through net10.0 to serve both worlds.
Deployment
Included as prod_application with 2 releases via classic \finance\tax-service Dev and \finance\tax-service Release pipelines (the WCF path). Four YAML pipelines are in the repo: build-api.yml (builds/deploys the API to an AWS ECS container plus packages), build.yml (WCF build), integration-test.yml (Reqnroll tests against the deployed API) and deploy-mongodb.yml (Mongo data scripts).
Dependencies
Internal packages: TC.ConnectionBroker.* incl. Mongo broker (tc-connectionbroker), TC.Exceptions.WebApiClient (tc-exceptions), TC.Phenix.ApplicationFramework (application-framework), TC.Cache.Specialised.PhenixFeature (phenix-feature-service), TC.DestinationManagement.API.Client and TC.Destination.Queries.GraphQL.Client (phenix-destination-management), TC.ContactCentre.ServiceClient (phenix-contact-centre-wcf), plus TC.Phenix.Services.Client for the BackOffice booking service (hosting repo not confidently identified). External: AWS Cognito machine-to-machine auth for API consumers.
Data stores
MongoDB Tax database (tax zones, percentages, places), deployed and migrated by pipeline-run change scripts. The legacy WCF path holds no data of its own — it delegates to the BackOffice booking service.
Integration points
Inbound SOAP/WCF (legacy) and JWT-secured REST (modern); outbound WCF to the BackOffice booking service, REST/GraphQL to destination management, Cognito token exchange.
Code health
Good: seven test projects spanning unit tests for both stacks, Reqnroll BDD integration tests run against the deployed API by a dedicated pipeline, and test helpers; an exemplary README documenting packages, pipelines and both solutions. Very active (last commit 2026-07-23).
Modernisation risks
Medium, trending low: the modernisation is well underway and well engineered, but production releases still track the legacy .NET Framework 4.7.2 WCF service, and consumers must migrate via the toggle/client packages before it can be retired. Until then the repo carries a dual-stack maintenance burden and a live WCF/SOAP surface.