Monica Application Microservice

Monica Application Microservice

Overview

Use this skill to shape Monica application projects as DDD-aligned microservices. It defines where each subdomain lives, how shared contracts are exposed, and how services collaborate without collapsing boundaries.

Workflow

1. Read [00-solution-layout.md](references/00-solution-layout.md) to choose the target solution structure.
2. Use [01-create-subdomain-and-service.md](references/01-create-subdomain-and-service.md) when adding a new subdomain or service trio.
3. Use [02-protocol-platform-and-service-contracts.md](references/02-protocol-platform-and-service-contracts.md) before adding cross-service requests, DTOs, or events.
4. Use [03-service-boundaries-and-collaboration.md](references/03-service-boundaries-and-collaboration.md) to keep service ownership and dependency direction clean.
5. Hand unit implementation to monica-application-project-unit-development, then finish with [04-delivery-checklist.md](references/04-delivery-checklist.md).

Core Rules

• Split by business capability and data ownership, not by transport or technical layer alone.
• Keep the shared platform split explicit: Platform.BuildingBlocks for project-agnostic infrastructure extensions, Platform.Infrastructure for solution-owned infrastructure wiring, and Platform.Protocol for shared business language.
• Use the strict solution-project reference chain {Subdomain}Service.API -> {Subdomain}Service.Domain -> Platform.Infrastructure -> Platform.Protocol -> Platform.BuildingBlocks.
• Put project-common library references in Platform.BuildingBlocks. Keep service-only package references in the owning {Subdomain}Service.Domain project.
• Keep Shared/Platform.Protocol/PublishedLanguages stable and explicit. Do not leak persistence entities across service boundaries.
• Keep each subdomain service independently evolvable: API, Domain, and migrations move together.
• Keep pure helper code in the service Domain project under Utilities/, using Utils* names.
• Configure default ApplicationService routing once in {Subdomain}Service.API/Program.cs with AutoControllerConfig(DefaultRoutePrefix = "api/v1", DomainName = "{Subdomain}"), and keep handlers focused on request-level method routes.
• Treat the service API project and AppHost or gateway entry points as adapters or composition only. Keep AppHost or gateway projects down to the project file and Program.cs; business ProjectUnits belong in the service's API and Domain projects.
• When host composition needs a Configuration ProjectUnit during registration, register Mo.AddConfiguration(...) first and call Mo.RegisterInstantly(builder) before later registrations depend on those options.
• Keep .slnx solution folders aligned with the physical layout under src/AppHost, src/Shared, src/Services, and src/Migrations.

Reference Navigation

• Solution structure: [00-solution-layout.md](references/00-solution-layout.md)
• New subdomain/service workflow: [01-create-subdomain-and-service.md](references/01-create-subdomain-and-service.md)
• Protocol platform and service contracts: [02-protocol-platform-and-service-contracts.md](references/02-protocol-platform-and-service-contracts.md)
• Service boundaries and collaboration: [03-service-boundaries-and-collaboration.md](references/03-service-boundaries-and-collaboration.md)
• Completion checklist: [04-delivery-checklist.md](references/04-delivery-checklist.md)

Scope Notes

• This skill defines solution layout and service-level boundaries.
• Use monica-application-project-unit-development whenever the next step is to implement requests, handlers, entities, repositories, events, configurations, or jobs.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Tairitsua
• Source: Tairitsua/Monica
• License: MIT
• Homepage: https://monica.dpdns.org/

Install and usage instructions live in the source repository linked above.