Application Services¶

Executive Summary¶

Application Services defines the logical use-case coordination layer inside each Spring Boot Modulith module. Application services are the primary boundary for commands, queries, transactions, policy checks, domain services, repositories, events, integrations, and AIOS requests.

Why This Exists¶

Algosure needs a consistent component model that keeps business behavior inside owning modules and prevents frontends, integrations, analytics, AIOS, or other modules from mutating state directly.

Owner¶

The owner is the Chief Product Officer and Enterprise Architect.

Business Value¶

Application service boundaries make module ownership easier to review, test, secure, audit, and evolve.

Application Service Position¶

flowchart TB
    API[API Boundary]
    App[Application Service]
    Policy[Policy and Authorization Checks]
    Domain[Aggregates and Domain Services]
    Repo[Module Repositories]
    Events[Domain Events]
    Integration[Integration Boundary]
    AIOS[AIOS Boundary]

    API --> App
    App --> Policy
    App --> Domain
    App --> Repo
    Domain --> Events
    App --> Integration
    App --> AIOS

Responsibilities¶

Responsibility	Meaning
Use-case coordination	Orchestrates a business use case without becoming the business rule owner.
Tenant and actor context	Requires tenant, actor, authorization, consent, and audit context before material work.
Transaction boundary	Coordinates state changes inside the owning module transaction boundary where required.
Policy checks	Applies module-owned and platform policy before executing commands.
Domain invocation	Loads aggregates, calls domain services, enforces invariants through the domain model.
Repository access	Uses only repositories owned by the same module.
Event publication	Publishes domain events produced by the module's domain model.
Integration coordination	Requests external work through governed integration boundaries.
AIOS coordination	Requests AIOS work and accepts outputs through module-owned workflows.

Application Services by Module¶

Module	Example Application Service Areas
Identity	Membership management, role assignment, permission checks, session governance, API key lifecycle.
Organization	Tenant onboarding, organization profile management, operating context updates, user organization association.
Compliance	Evidence intake, readiness review, expiry monitoring, verification recording, compliance exception handling.
Opportunity	Tender intake, opportunity matching, saved opportunity management, recommendation review, deadline monitoring.
Bid	Workspace creation, bid planning, contributor coordination, document package preparation, approval readiness.
Contract	Award conversion, milestone management, delivery tracking, invoice reference handling, closeout coordination.
Supplier	Supplier onboarding, profile updates, quote recording, performance review, trust state changes.
Marketplace	Supplier need identification, listing management, quote request coordination, marketplace match review.
Funding	Funding need assessment, readiness evaluation, partner application coordination, offer review, repayment tracking.
Learning	Learning path assignment, course progress tracking, quiz completion, certificate issuance, maturity review.
Intelligence	AI task request handling, reasoning record management, memory update workflow, explanation packaging.
Notification	Notification request handling, preference evaluation, reminder scheduling, delivery status recording.
Analytics	Metric snapshot generation, report preparation, KPI threshold evaluation, executive insight preparation.
Billing	Subscription lifecycle, entitlement evaluation, invoice lifecycle, payment status interpretation, renewal handling.
Administration	Feature flag changes, policy configuration, support actions, audit review workflows, platform governance updates.

Domain Services¶

Domain services belong inside the owning module and express business logic that does not naturally fit inside one aggregate.

Rule	Meaning
Domain services are not orchestration scripts	They express domain behavior, calculations, rules, and decisions.
Domain services stay module-local	They must not become cross-domain utilities.
Application services call domain services	External callers should not bypass application services to invoke domain services directly.
Domain services may produce events	Domain-significant outcomes should produce module-owned events.

Repository Rules¶

Rule	Meaning
Repositories are module-private	Only the owning module's application and domain services use its repositories.
Repositories persist owned aggregates	Repository boundaries follow aggregate and module ownership.
Cross-module queries use contracts	Another module must use API, event projection, or approved query boundary, not a repository.
Persistence does not define the Domain	Database convenience must not reshape business ownership.

API Boundary Ownership¶

API boundary components belong to the module that owns the use case or query. They translate external or frontend requests into application service calls and return governed responses without exposing internal aggregates.

Rule	Meaning
API owns contract, not business rules	Business rules remain in application, domain, and policy components.
API responses are stable contracts	Responses should not leak internal entity structure.
API authorization is enforced with backend context	Frontend assumptions are not sufficient for authorization.
API boundaries preserve tenant context	Every inbound request must resolve authorized tenant context before material work.

Non-Implementation Boundary¶

This document does not define controller classes, service method names, transaction annotations, repository interfaces, DTOs, validation libraries, or API routes.