Skip to content

ConnectSoft SaaS platform — solution plan

This page is the implementation-oriented companion to the company-wide SaaS vision. It describes how bounded contexts become template repositories, how they compose with the Platform Template and Blazor shell / MFEs, and how published surfaces (NuGet ServiceModel packages) keep gateways and UIs decoupled from domain code.

Scope of this program

In scope: Tenants, Product catalog, Entitlements, Billing, Metering; shared ConnectSoft.Extensions.Saas.* libraries; ConnectSoft.Saas.*Template backend templates; ConnectSoft.Blazor.Shell.Saas; context MFE templates.
Out of scope (separate initiatives): dedicated Audit & compliance, Notifications & webhooks, and Configuration / feature-flag platforms as first-class template programs here.

Goals

  • One DDD microservice per bounded context, generated from a named template repo (ConnectSoft.Saas.<Context>Template) that embeds ConnectSoft.BaseTemplate as a Git submodule (factory-standard kernel).
  • Stable API contracts via ServiceModel (and RestApi / Grpc) packages—same pattern as Identity Backend—so API Gateway, BFF, shell, and peer services consume contracts only.
  • Frontend composition via ConnectSoft.Blazor.Shell.Saas and Blazor MFE templates aligned with existing Identity / Authorization Server MFE examples.
  • Cross-cutting SaaS infrastructure in ConnectSoft.Extensions.Saas.* (multi-repo, one NuGet package per repo), introduced after templates prove shape (Phase 2 in the roadmap).

End-to-end view

flowchart TB
  subgraph published [Published surfaces]
    SM[ServiceModel NuGet packages]
    GW[API Gateway]
    Shell[ConnectSoft.Blazor.Shell.Saas]
    MFE[Blazor MFE modules]
  end
  subgraph runtime [Bounded context services]
    T[Tenants svc]
    P[Products catalog svc]
    E[Entitlements svc]
    B[Billing svc]
    M[Metering svc]
  end
  subgraph gen [Template layer design-time]
    Tpl[ConnectSoft.Saas.*Template repos]
    Base[ConnectSoft.BaseTemplate submodule]
    Base --> Tpl
  end
  Tpl -.->|dotnet new output| runtime
  runtime --> SM
  SM --> GW
  SM --> Shell
  SM --> MFE
  IdP[Identity Backend / Auth Server] -.-> GW
  IdP -.-> Shell
Hold "Alt" / "Option" to enable pan & zoom

DDD microservices and repositories (design-time map)

Layer Responsibility Repository naming (examples)
Layer 1 — Shared SaaS libraries Tenant context abstractions, ASP.NET Core middleware, options, testing helpers ConnectSoft.Extensions.Saas.Abstractions, .AspNetCore, .Options, .Testing (each its own Git repo)
Layer 2 — Base kernel Shared microservice layout without domain ConnectSoft.BaseTemplate (Git submodule; see Template layering and reuse)
Layer 3 — SaaS backend templates Per–bounded-context dotnet new pack + runnable scaffold ConnectSoft.Saas.TenantsTemplate, ConnectSoft.Saas.ProductsCatalogTemplate, …
Layer 3 — Front shell Portal host, MFE registry, navigation, tenant/edition ConnectSoft.Blazor.Shell.Saas
Layer 3 — MFE templates Admin/self-service surfaces per context e.g. ConnectSoft.Blazor.Mfe.Saas.* (follow existing MFE naming patterns)
Composition Multi-repo product composition Platform Template (templates-dependencies.md)

Service repos deployed to production are produced from template repos (rename, extend, or fork)—this plan treats templates as the factory deliverable; product-specific service repos are a downstream concern.

Templates and Platform Template

  • dotnet new template packs live inside each ConnectSoft.Saas.*Template repository; developers install the pack and generate a new solution for a bounded context.
  • The Platform Template remains the composition vehicle for a full SaaS product: gateway, identity stack, documentation site, and generated microservices wired together. SaaS-specific services appear as instances created from SaaS template repos, not as a single monolith.
  • See templates-dependencies.md for how Platform Template relates to Microservice, API Gateway, Authorization Server, and Identity Backend templates; SaaS context templates plug in as additional microservice instances in that picture.

Published surfaces (ServiceModel standard)

Canonical architecture guidance: Service Model (Layer 3 boundary, DTO patterns, versioning). This section applies that model to SaaS bounded-context templates.

Structural parity: each ConnectSoft.Saas.<Context>Template repo follows the same ServiceModel-at-the-edge story as the Identity Backend Template (solution structure): Application hosts use cases; ServiceModel projects are the only public NuGet surface for external callers.

Package identity

NuGet Pattern Example
Contracts + typed clients ConnectSoft.Saas.<Context>.ServiceModel ConnectSoft.Saas.Tenants.ServiceModel
REST controllers (optional split) ConnectSoft.Saas.<Context>.ServiceModel.RestApi ConnectSoft.Saas.ProductsCatalog.ServiceModel.RestApi
Code-first gRPC adapters ConnectSoft.Saas.<Context>.ServiceModel.Grpc ConnectSoft.Saas.Billing.ServiceModel.Grpc

Context uses the bounded-context short name (Tenants, ProductsCatalog, Entitlements, Billing, Metering). Company portfolio mirror: ConnectSoft.CompanyDocumentationdocs/product-portfolio/platforms/saas-solution-platform/api-contract-specification.md.

Versioning (SemVer)

  • Breaking HTTP path, request/response DTO shape, or gRPC ServiceModel interface change → major bump on the affected ServiceModel NuGet(s).
  • Additive optional fields, new endpoints, or backward-compatible operations → minor bump.
  • Shell, MFEs, and gateway pin upper-bound compatible ranges; CI on each template repo validates additive-only OpenAPI diffs within a major (see SaaS cross-repo published language § Enforcement).

Edge consumers (ServiceModel only)

Gateways, portal shell, and MFEs consume ConnectSoft.Saas.*.ServiceModel* NuGets for business API calls. Authentication uses the Authorization Server / OIDC stack—not SaaS DomainModel packages. Full matrix: SaaS cross-repo published language — Edge consumer package matrix.

Edge consumer SaaS ServiceModel NuGets Auth / OIDC Application / Domain
API Gateway Yes — route, aggregate OpenAPI, typed downstream clients JWT/OIDC validation middleware; links to Authorization Server Forbidden
ConnectSoft.Blazor.Shell.Saas (BFF) Yes — server-side calls to bounded contexts OIDC client via Authorization Server; user claims for tenant scope Forbidden
Blazor MFE (per context) Yes — ServiceModel clients only at UI edge OIDC via shell/host; no direct domain references Forbidden
Peer microservice (SaaS context) Yes — integration REST/gRPC As configured per service; not a substitute for ServiceModel Forbidden

Peer-to-peer which context consumes which ServiceModel NuGet: ServiceModel matrix in the same document.

Concrete repositories (delivered)

All five repos live as separate Git repositories under C:\Git\ConnectSoft\SAAS\, each Layer-3 extender of ConnectSoft.BaseTemplate via base-template/ submodule, and each hosts one dotnet new short name:

Short name Repo Aggregate root
connectsoft-saas-tenants ConnectSoft.Saas.TenantsTemplate Tenant
connectsoft-saas-productscatalog ConnectSoft.Saas.ProductsCatalogTemplate Product
connectsoft-saas-entitlements ConnectSoft.Saas.EntitlementsTemplate Entitlement
connectsoft-saas-billing ConnectSoft.Saas.BillingTemplate Subscription
connectsoft-saas-metering ConnectSoft.Saas.MeteringTemplate UsageMeter

Per-repo assets shipped:

  • Application + ApplicationModel + DomainModel (+ .Impl) + EntityModel
  • ServiceModel + ServiceModel.RestApi + ServiceModel.Grpc (PUBLIC NuGets; REST + gRPC only)
  • MessagingModel + FlowModel + FlowModel.MassTransit (MassTransit + built-in outbox; PUBLIC event NuGet)
  • ActorModel + ActorModel.Orleans (Orleans; grains tenant-scoped; PUBLIC grain contract NuGet)
  • PersistenceModel + PersistenceModel.NHibernate (NHibernate multi-dialect; no Mongo)
  • DatabaseModel.Migrations (FluentMigrator, dialect-agnostic; no outbox tables)
  • SchedulerModel + SchedulerModel.Hangfire, Options, Metrics, ArchitectureModel
  • InfrastructureModel (Bicep / Terraform / Pulumi)
  • DiagramAsCodeModel (Structurizr + PlantUML + Mermaid)
  • Deployment/docker-compose/ + Deployment/kubernetes/ + Deployment/helm/<context>
  • observability/ (OTel Collector, Prometheus, Grafana dashboards, Loki, Tempo/Jaeger, alerts)
  • docs/ + mkdocs.yml (MkDocs Material site)
  • Azure Pipelines: azure-pipelines.yml (app), azure-pipelines-service-model.yml, azure-pipelines-messaging-model.yml, azure-pipelines-actor-model.yml, azure-pipelines-infrastructure-model.yml, azure-pipelines-documentation.yml, azure-pipelines-template.yml