Shared Monica-native DDD ProjectUnit development guidance for application projects. Use when creating, naming, placing, or refactoring ApplicationService, RequestDto, 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.
التثبيت
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Shared Monica-native DDD ProjectUnit development guidance for application projects. Use when creating, naming, placing, or refactoring ApplicationService, RequestDto, 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.Framework/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.
For HTTP-exposed ApplicationService handlers, prefer the controller route pattern api/{version}/{DomainName(PascalCase)} and keep only the request-specific segment on the handler method, such as GET api/v1/Documentation/tree.
If host composition must consume a Configuration ProjectUnit during registration, register Mo.AddConfiguration(...) first and then call Mo.RegisterInstantly(builder) before the dependent registration code runs.
