develop-domain-model

Implements one Go domain layer unit through a TDD cycle of failing test, implementation, and refactoring.

Updated Sep 14, 2026
One-click install
npx skills add https://github.com/nakamori-naoya/go-convention-plugins --skill develop-domain-model-nakamori-naoya
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: develop-domain-model
Source: https://github.com/nakamori-naoya/go-convention-plugins/tree/main/plugins/go-convention/skills/develop-domain-model
Command: npx skills add https://github.com/nakamori-naoya/go-convention-plugins --skill develop-domain-model-nakamori-naoya

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Implementing a Go domain aggregate or value object from a domain-model document often mixes test writing, implementation, and cleanup into an unstructured process. This Skill enforces a disciplined TDD cycle—write the failing test, verify red, implement, verify green, then refactor—so each domain unit is completed against the document's BDD specifications without skipping verification steps. ## Core Features & Use Cases - Structured TDD Cycle: Executes a fixed playbook (fix-unit, write-failing-test, run-red, implement, run-green, refactor, align-errors, report) where each step has explicit completion conditions. - Convention Delegation: Calls separate convention skills for test style, domain implementation patterns, Go language rules, and error sentinel alignment rather than redefining them. - BDD Traceability: Maps BDD IDs from the domain-model document directly into table-driven test cases and verifies coverage mechanically. - Use Case: Given a domain-model document describing a "Reservation" aggregate with its BDD table, produce the *_test.go file first, confirm it fails for the right reason, implement the typestate aggregate and value objects, and finish with gofmt/vet/golangci-lint clean code. ## Quick Start Implement the Reservation aggregate from this domain-model document with TDD, writing the failing tests from its BDD table first.

Frequently Asked Questions about develop-domain-model

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

FAQPage Schema
How do I implement a Go domain aggregate with TDD?▼

Fix the unit from the domain-model document's BDD table, write the failing test first, verify it fails because the target is unimplemented, then write the minimal implementation to turn it green. Finish by refactoring under language conventions without changing behavior.

How to map BDD scenarios to Go table-driven tests?▼

Each BDD ID from the domain-model document becomes a test case `id` or trailing comment in the table-driven test. The cycle mechanically verifies BDD coverage so no scenario from the document is left untested.

Does this TDD workflow work with testify in Go 1.27?▼

Yes, the workflow assumes Go 1.27 with testify as its baseline. The domain layer uses no database, containers, mocks, or stubs, so tests run as pure unit tests with `go test -shuffle=on` and race checks.

What counts as a valid red test before implementing?▼

A valid red is a failure classified as either a compile error because the target type, method, or sentinel does not exist yet, or an assertion failure where the operation does not return the document's expected result. Unrelated existing failures or environment issues do not qualify.

When should error sentinels be aligned during TDD?▼

Sentinel alignment runs only when the unit added new sentinels or changed their messages. The error convention skill then ensures each sentinel maps one-to-one with a rejection reason in the domain-model document while tests stay green.

What are the scope limits of domain layer TDD?▼

The unit covers exactly one aggregate or one value object with its document-assigned BDD scenarios. Persistence, usecase orchestration, RPC handlers, and domain knowledge discovery are out of scope and handled by their own separate entry points.