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)

  • Each backend template ships NuGet-packable ServiceModel projects (REST DTOs, client facades, optional gRPC stubs) following the same consumer story as the Identity Backend: no references from consumers to Application or Domain layers.
  • Versioning: breaking HTTP/gRPC contracts bump ServiceModel major version; shell and MFEs pin compatible ranges.
  • Consumers: API Gateway (routing and aggregation), ConnectSoft.Blazor.Shell.Saas (BFF calls), MFEs (typed clients), and other microservices (integration).