monica-project-unit-development

Guide Monica-native DDD ProjectUnit creation, naming, and placement for business features.

13|6|Updated Feb 19, 2025
One-click install
npx skills add https://github.com/Tairitsua/Monica --skill monica-project-unit-development
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: monica-project-unit-development
Source: https://github.com/Tairitsua/Monica/tree/main/.claude/skills/monica-project-unit-development
Command: npx skills add https://github.com/Tairitsua/Monica --skill monica-project-unit-development

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Provides clear, Monica-aligned guidance to decide which ProjectUnits to create, how to name and place them, and how to keep boundaries correct so teams avoid scattering business rules, misplacing repositories, or breaking discovery conventions.

Core Features & Use Cases

  • Unit selection guidance: Maps feature shapes to the smallest correct set of ProjectUnits (ApplicationService, RequestDto, DomainService, Entity, Repository, DomainEvent, handlers, jobs, configuration).
  • Naming, placement & boundary rules: Enforces Monica.Framework discovery conventions and folder placement for both microservice and modular-monolith solutions.
  • Templates & checklists: Includes handler, domain service, entity, repository, event, job, and configuration templates plus a pre-deployment feature checklist to ensure consistency and scanability.
  • Use case: Use when adding a new use case, creating an aggregate, introducing events or background jobs, or deciding where to place repository implementations.

Quick Start

Use this skill to choose the ProjectUnits, their names, and folder placement for a new feature and produce a one-page checklist of files, templates, and registration steps.

Frequently Asked Questions about monica-project-unit-development

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide which DDD project units to create for a new business feature?

To decide which DDD project units to create, map the feature shape to the smallest correct set of units like ApplicationService, DomainService, Entity, Repository, and handlers. This ensures business rules are not scattered and boundaries remain correct.

What are the naming and folder placement rules for DomainEvent and DomainEventHandler in a modular monolith?

DomainEvent and DomainEventHandler placement in a modular monolith must follow Monica.Framework discovery conventions. Enforcing these specific folder boundaries and naming rules ensures project-unit discoverability and prevents misplacing repository implementations.

When do I need to create a Repository versus a DomainService for my aggregate?

You need a Repository for data persistence of an aggregate, while a DomainService handles domain logic that does not naturally belong to an Entity. Using templates helps assign these responsibilities correctly without breaking discovery conventions.

Does this Monica DDD guidance work for both microservice and modular-monolith workflows?

Yes, the Monica DDD guidance works for both microservice and modular-monolith workflows. It enforces naming, placement, and boundary rules for project units like ApplicationService and RequestDto across both architectural styles.

What's the best way to organize RecurringJob and TriggeredJob registration configuration in DDD?

The best way to organize RecurringJob and TriggeredJob configuration is by using dedicated project unit templates. This approach satisfies registration-time configuration requirements and includes a pre-deployment checklist for consistency.

Why does my ApplicationService fail project-unit discovery in Monica Framework?

ApplicationService project-unit discovery fails when naming and folder placement do not match Monica Framework conventions. Using a checklist to verify boundaries and configuration placement ensures files are correctly scanned and discovered.