Shared Monica-native DDD ProjectUnit development guidance for application projects. Use when creating, naming, placing, or refactoring ApplicationService, RequestDto, request-owned HTTP or published RPC endpoint contracts, DomainService, Entity, Repository, DomainEvent, DomainEventHandler, LocalEventHandler, Configuration, RecurringJob, or TriggeredJob types, or when deciding which ProjectUnits a new feature requires in either microservice or modular monolith solutions.
Installation
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Shared Monica-native DDD ProjectUnit development guidance for application projects. Use when creating, naming, placing, or refactoring ApplicationService, RequestDto, request-owned HTTP or published RPC endpoint contracts, DomainService, Entity, Repository, DomainEvent, DomainEventHandler, LocalEventHandler, Configuration, RecurringJob, or TriggeredJob types, or when deciding which ProjectUnits a new feature requires in either microservice or modular monolith solutions.
Monica Application ProjectUnit Development
Overview
Use this skill for unit-level application development in Monica-based DDD projects. It defines the common ProjectUnit language shared by both monica-application-microservice and monica-application-modular-monolith.
Workflow
Start with the architecture skill to choose the target subdomain, project, and folder layout.
Load only the template references relevant to the units you are creating or changing.
Keep the boundary thin: ApplicationService returns Res, while internal DomainService, repository, and entity logic stay on normal .NET return types and exceptions.
Prefer rich entities and value objects over procedural handlers that directly mutate persistence state.
Ground Rules
Use Monica-native base classes and interfaces only. Do not introduce Our* wrappers or FIPS-specific conventions.
Follow the naming, placement, and boundary rules in 01-project-unit-naming-and-boundaries.md. These rules are aligned with the current Monica.ProjectUnits discovery behavior.
Keep persistence concerns in repositories and persistence classes, not in request handlers.
Keep repository implementations in the owning subdomain or service infrastructure boundary. Do not move a repository or adapter to Platform just because it uses an external library; only project-common reusable infrastructure belongs in Platform.
Keep contracts stable: requests, DTOs, and events are not persistence entities.
If a handler returns Res<string>, use Res.Ok<string>(value) instead of Res.Ok(value) to avoid the non-generic string overload.
Make HTTP contracts request-owned. Put [ApiEndpoint] on the request type and keep route, verb, binding, and optional operation name off the ApplicationService handler.
A request is published for generated RPC clients only when it is attributed source in the exact namespace *.PublishedLanguages.Domain{DomainName}.Requests. Attributed requests outside that boundary remain local HTTP endpoints.
Put [assembly: WebApiGenerationConfig(...)] in each assembly that owns attributed requests. Protocol assemblies select the required RpcClientTargets; local-only assemblies normally use None.
Do not add MVC [Http*], [Route], or [From*] attributes to generated ApplicationService endpoints. The request contract is the single endpoint authority.
Use ApplicationService only for HTTP-exposed mediator handlers. If a request is intentionally internal and must have no HTTP endpoint, implement IRequestHandler<TRequest, TResult> as a normal transient dependency instead of omitting [ApiEndpoint] from an ApplicationService.
Register monica.AddConfiguration() inside builder.AddMonica(...). Runtime consumers receive configuration ProjectUnits through IOptions<T>, IOptionsSnapshot<T>, or IOptionsMonitor<T>; composition code that needs bootstrap values reads builder.Configuration directly and passes explicit values into module options.
