- Home
- Skills
- Akiramei
- Blazor Enterprise Architecture Poc
- Vsa Boundary Modeler
vsa-boundary-modeler_skill
- C#
1
GitHub Stars
2
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill akiramei/blazor-enterprise-architecture-poc --skill vsa-boundary-modeler- boundary-essentials.md2.7 KB
- SKILL.md5.8 KB
Overview
This skill helps model the Boundary pattern for Blazor VSA features that have a UI. It reminds developers to design user Intents, implement Entity.CanXxx() methods for operation permission, and keep BoundaryService focused on data retrieval and delegation. The goal is to place decision logic correctly in Entities and avoid burying business rules in UI-layer services.
How this skill works
The tool guides you through three main steps: define Intents representing user actions, implement corresponding CanXxx() methods on Entities that return BoundaryDecision, and implement BoundaryService methods that fetch data and delegate permission checks to Entities. It highlights forbidden patterns (business logic inside BoundaryService) and offers examples for priority scenarios where additional context must be passed into Entity checks. It also supplies a simple BoundaryDecision type pattern for allow/deny results.
When to use it
- Designing or implementing features that expose UI actions (forms, lists, detail pages).
- Enabling/disabling UI controls (buttons, menu items) based on business rules.
- When you need a clear separation between data access and business decision logic.
- Implementing intent-driven flows where user intention maps to domain behaviors.
- Handling priority or reservation rules that affect operation permission.
Best practices
- List user Intents first and map each to an Entity.CanXxx() method.
- Keep BoundaryService limited to retrieval, existence checks, and delegation.
- Make CanXxx() return a BoundaryDecision with IsAllowed and optional Reason.
- Pass necessary context (e.g., priority actor IDs) into Entity checks rather than centralizing logic.
- Avoid duplicating business rules in UI or service layers; test decisions on the Entity level.
Example use cases
- Order screen: define Pay/Cancel/View intents and implement Order.CanPay()/CanCancel().
- Reservation list: decide button enablement by calling Entity.CanBorrow(memberId, readyReserverId).
- Detail form: BoundaryService fetches entity and delegates CanUpdate() to control edit state.
- Cancel flow: BoundaryService returns Deny with a user-facing reason when entity disallows action.
- Bulk UI: prefetch entities and call their CanXxx() methods to determine available bulk operations.
FAQ
BoundaryService should only fetch data, check existence, and delegate. All business-rule decisions belong in Entity.CanXxx() methods.
How do I communicate why an action is denied to the UI?
Have CanXxx() return a BoundaryDecision containing IsAllowed and an optional Reason string; BoundaryService forwards that to the UI.