ddd-domain-model-first

Guides test-first domain model development following DDD layering order.

Updated Jun 23, 2026
One-click install
npx skills add https://github.com/j5ik2o/marp-ai-base --skill ddd-domain-model-first-j5ik2o
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ddd-domain-model-first
Source: https://github.com/j5ik2o/marp-ai-base/tree/main/.agents/skills/ddd-domain-model-first
Command: npx skills add https://github.com/j5ik2o/marp-ai-base --skill ddd-domain-model-first-j5ik2o

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When building applications with Domain-Driven Design, starting from infrastructure or UI concerns often distorts the domain model, leaks technical concerns into business logic, and makes testing difficult. This Skill provides a disciplined development procedure that keeps the domain model pure and testable. ## Core Features & Use Cases - Test-First Domain Modeling: Define domain model behavior as tests first, then implement value objects, entities, and aggregates to satisfy them. - Ordered Development Workflow: Build in the sequence of domain model, in-memory repository, use cases, then infrastructure and interface adapters. - In-Memory Repository Pattern: Implement repository interfaces backed by in-memory collections so use cases can be tested without a database. - Use Case: When starting a new feature like task management, write tests for the Task aggregate's behavior first, create an in-memory TaskRepository, implement CompleteTaskUseCase against it, and only then connect the real database and controllers. ## Quick Start Ask the AI to design and implement a new feature using test-first domain modeling with an in-memory repository before adding infrastructure.

Frequently Asked Questions about ddd-domain-model-first

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

FAQPage Schema
How do I start DDD development with a test-first approach?

Begin by defining the domain model's expected behavior as tests, including edge cases and constraints. Then implement value objects, entities, and aggregates to satisfy those tests, and refactor to clarify responsibilities before moving to repositories and use cases.

How to test use cases without a database in DDD?

Define a repository interface in the domain layer and create an in-memory implementation backed by a simple collection. Inject it into the use case during tests so you can verify success and failure scenarios without any database dependency.

What order should I build layers in domain-driven design?

Build in this order: domain model first, then in-memory repository, then use cases, and finally infrastructure and interface adapters. This prevents database schemas and framework constraints from distorting the domain design.

Is this DDD workflow tied to a specific programming language?

No, the principles are language-agnostic and apply to any stack. The guide uses TypeScript examples for tests and implementations, but the same test-first, domain-first sequence works in other languages.

What are the risks of not following the domain-model-first order?

Starting from infrastructure distorts entity design around database schemas, leaks persistence and transaction concerns into business logic, and makes models hard to test. It also reduces changeability and undermines the ubiquitous language shared with domain experts.