realize-application-service

Implements a thin application service that orchestrates aggregates and ports without duplicating domain rules.

Updated Jun 12, 2026
One-click install
npx skills add https://github.com/lucolucus/mismagent --skill realize-application-service-lucolucus
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: realize-application-service
Source: https://github.com/lucolucus/mismagent/tree/main/plugins/mismagent/skills/realize-application-service
Command: npx skills add https://github.com/lucolucus/mismagent --skill realize-application-service-lucolucus

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When building a use-case block in a DDD-style architecture, developers often re-implement aggregate invariants inside the service layer or reach directly into another bounded context's internals, breaking boundary integrity. This Skill guides the worker to realize a thin Application Service that delegates rules to the owning aggregate root and reads other contexts only through consumer-owned ports. ## Core Features & Use Cases - Boundary-honoring orchestration: Routes mutations through the aggregate root that owns the invariant and reads foreign contexts only via the port's interface in primitives. - Bounce detection: Flags any raw-field evaluation (e.g. attivo == true) as a domain decision that belongs in a root/port predicate, not the service. - AC-testing with fake ports: Translates the user's natural-language tests_nl into acceptance tests verified against a fake port, keeping the block green on its own while preserving the aggregate's invariant tests. - Use Case: While building an order-confirmation use-case, the worker calls the Order aggregate root to apply state changes, reads pricing through a PricingPort interface, and verifies behavior with a fake port before the worker-composer welds real implementations in D2. ## Quick Start Ask the worker to realize the application-service block from the building-block manifest, honoring the aggregate boundary and testing with a fake port.

Frequently Asked Questions about realize-application-service

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

FAQPage Schema
How do I implement an application service without duplicating domain logic?

Keep the service thin: delegate every invariant to the aggregate root that owns it and never re-evaluate raw fields yourself. If you catch a check like `attivo == true`, move it into a predicate on the root or port such as `vendibile`.

How should an application service read data from another bounded context?

Read the other context only through a consumer-owned port interface expressed in primitives. Never import the other context's source code or domain types; the port's signature is the only contract.

How do I test a use-case without the real external dependency?

Write acceptance tests against a fake implementation of the port so the block stays green on its own. The real-on-real integration welding is performed later by the worker-composer in the D2 phase.

What does green on its own mean for an application service block?

It means the use-case's AC-tests pass with a fake port and the owning aggregate's invariant tests also stay green. If your service breaks a root invariant, the block is not considered complete.

When should logic live in the service versus the aggregate?

Only orchestration belongs in the service: calling roots, ports, and repositories. Any domain decision or rule evaluation belongs in the aggregate root or a port predicate, never in the service layer.