agentsclimarketplace

Domain modeling

Skill xfoundries/domain-architecture-skills/skills/domain-modeling

Source-aware architecture guidance for business-domain systems using Domain-Driven Design, Layered Architecture, Onion Architecture, Hexagonal Architecture / Ports and Adapters, and CQRS.

Install
npx -y skills add xfoundries/domain-architecture-skills --skill domain-modeling

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when modeling business domains from requirements, user stories, workflows, event storming notes, existing systems, database tables, or APIs; identifying bounded contexts, ubiquitous language, business commands, aggregates, entities, value objects, invariants, domain events, domain services, repositories, read needs, or reviewing whether a proposed model is behavior-rich rather than table-driven.

SKILL.md

2.5 KB, 427 tokens by cl100k_base, as published. Nobody here has run it

Domain Modeling

Purpose

Use this skill to turn business requirements into an explicit domain model before implementation. It is framework-neutral and should not assume jfoundry, Spring, .NET, Go, Python, or any specific architecture style.

Do not treat domain modeling notes as ceremony for simple CRUD changes. Use them when a change introduces business rules, lifecycle state, invariants, domain events, cross-aggregate coordination, or ambiguous domain language.

Core Workflow

  1. Start from business workflows, not tables or controllers.
  2. Extract language, commands, events, rules, states, exceptions, and external actors.
  3. Identify bounded-context candidates when terms or rules change meaning across workflows.
  4. Design aggregates around invariants and consistency boundaries.
  5. Produce the modeling output protocol before coding.
  6. Review for table-driven modeling, anemic behavior, oversized aggregates, and misplaced orchestration.

Reference Routing

  • Read references/input-analysis.md when starting from requirements, user stories, tickets, existing tables, APIs, or code.
  • Read references/event-storming.md when workflows are complex, event-heavy, or involve policies and external systems.
  • Read references/bounded-contexts.md when terms, ownership, data, or rules may differ across teams or subdomains.
  • Read references/aggregate-design.md when choosing aggregate roots, entities, value objects, invariants, repositories, or domain services.
  • Read references/modeling-output.md before producing the modeling note or asking for domain review.
  • Read references/review-and-antipatterns.md when reviewing a proposed model or checking for table-driven/anemic designs.

Ground Rules

  • Prefer domain terms from the business language. Avoid technical names such as manager, handler, data, record, wrapper, or config unless they are real domain terms.
  • Keep open domain questions visible. Do not silently hard-code guesses as business rules.
  • Do not force DDD patterns into low-complexity CRUD areas.
  • Treat architecture and framework mapping as a later step. First make the domain assumptions explicit.

What ships with it: 7 files

16.0 KB alongside SKILL.md

agents/

references/

Keep looking

Skills are one crate of 327,069. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.