Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
ruvnet avatar

V3 Ddd Architecture

  • 989 installs
  • 67k repo stars
  • Updated August 4, 2026
  • ruvnet/ruflo

v3 ddd architecture is a Claude Code skill that designs Domain-Driven Design bounded contexts and clean architecture for claude-flow v3 agent codebases suffering from monolithic god objects.

About

v3 ddd architecture is a Claude Code skill from ruvnet/ruflo for implementing Domain-Driven Design in claude-flow v3 agent projects. The skill decomposes god objects into bounded contexts, applies clean architecture separation, and uses a microkernel pattern for modular, testable agent code. It supports parallel domain modeling tasks and architecture analysis via claude-flow Task invocations. Developers reach for v3 ddd architecture when agent repositories become hard to test, boundaries blur between domains, or a refactor toward maintainable module boundaries is required mid-build.

  • Decomposes god objects (e.g. 1,440-line orchestrators) into bounded contexts
  • Implements clean architecture with modular, testable code structure
  • Uses microkernel pattern and context mapping for domain relationships
  • Parallel domain modeling tasks for task-management, session-management, health-monitoring and lifecycle domains
  • Produces core$domains/ structure with clean domain interfaces

V3 Ddd Architecture by the numbers

  • 989 all-time installs (skills.sh)
  • +3 installs in the week ending Aug 5, 2026 (Skillselion tracking)
  • Ranked #402 of 4,347 Backend & APIs skills by installs in the Skillselion catalog
  • Security screen: LOW risk (skills.sh audit)
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/ruvnet/ruflo --skill v3-ddd-architecture

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs989
repo stars67k
Security audit3 / 3 scanners passed
Last updatedAugust 4, 2026
Repositoryruvnet/ruflo

How do you refactor agent code into DDD bounded contexts?

Decompose monolithic god objects into clean, modular Domain-Driven Design bounded contexts for maintainable agent codebases.

Who is it for?

Developers refactoring large claude-flow v3 or agent monoliths into testable, domain-separated modules.

Skip if: Greenfield projects with no architecture debt or teams not using claude-flow v3 agent codebases.

When should I use this skill?

The user needs DDD boundaries, clean architecture, or god-object decomposition in a claude-flow v3 agent project.

What you get

DDD boundary map, bounded-context module structure, and clean-architecture refactor plan.

  • DDD boundary map
  • Bounded-context module plan

Files

SKILL.mdMarkdownGitHub ↗

V3 DDD Architecture

What This Skill Does

Designs and implements Domain-Driven Design (DDD) architecture for claude-flow v3, decomposing god objects into bounded contexts, implementing clean architecture patterns, and enabling modular, testable code structure.

Quick Start

# Initialize DDD architecture analysis
Task("Architecture analysis", "Analyze current architecture and design DDD boundaries", "core-architect")

# Domain modeling (parallel)
Task("Domain decomposition", "Break down orchestrator god object into domains", "core-architect")
Task("Context mapping", "Map bounded contexts and relationships", "core-architect")
Task("Interface design", "Design clean domain interfaces", "core-architect")

DDD Implementation Strategy

Current Architecture Analysis

├── PROBLEMATIC: core$orchestrator.ts (1,440 lines - GOD OBJECT)
│   ├── Task management responsibilities
│   ├── Session management responsibilities
│   ├── Health monitoring responsibilities
│   ├── Lifecycle management responsibilities
│   └── Event coordination responsibilities
│
└── TARGET: Modular DDD Architecture
    ├── core$domains/
    │   ├── task-management/
    │   ├── session-management/
    │   ├── health-monitoring/
    │   ├── lifecycle-management/
    │   └── event-coordination/
    └── core$shared/
        ├── interfaces/
        ├── value-objects/
        └── domain-events/

Domain Boundaries

1. Task Management Domain
// core$domains$task-management/
interface TaskManagementDomain {
  // Entities
  Task: TaskEntity;
  TaskQueue: TaskQueueEntity;

  // Value Objects
  TaskId: TaskIdVO;
  TaskStatus: TaskStatusVO;
  Priority: PriorityVO;

  // Services
  TaskScheduler: TaskSchedulingService;
  TaskValidator: TaskValidationService;

  // Repository
  TaskRepository: ITaskRepository;
}
2. Session Management Domain
// core$domains$session-management/
interface SessionManagementDomain {
  // Entities
  Session: SessionEntity;
  SessionState: SessionStateEntity;

  // Value Objects
  SessionId: SessionIdVO;
  SessionStatus: SessionStatusVO;

  // Services
  SessionLifecycle: SessionLifecycleService;
  SessionPersistence: SessionPersistenceService;

  // Repository
  SessionRepository: ISessionRepository;
}
3. Health Monitoring Domain
// core$domains$health-monitoring/
interface HealthMonitoringDomain {
  // Entities
  HealthCheck: HealthCheckEntity;
  Metric: MetricEntity;

  // Value Objects
  HealthStatus: HealthStatusVO;
  Threshold: ThresholdVO;

  // Services
  HealthCollector: HealthCollectionService;
  AlertManager: AlertManagementService;

  // Repository
  MetricsRepository: IMetricsRepository;
}

Microkernel Architecture Pattern

Core Kernel

// core$kernel$claude-flow-kernel.ts
export class ClaudeFlowKernel {
  private domains: Map<string, Domain> = new Map();
  private eventBus: DomainEventBus;
  private dependencyContainer: Container;

  async initialize(): Promise<void> {
    // Load core domains
    await this.loadDomain('task-management', new TaskManagementDomain());
    await this.loadDomain('session-management', new SessionManagementDomain());
    await this.loadDomain('health-monitoring', new HealthMonitoringDomain());

    // Wire up domain events
    this.setupDomainEventHandlers();
  }

  async loadDomain(name: string, domain: Domain): Promise<void> {
    await domain.initialize(this.dependencyContainer);
    this.domains.set(name, domain);
  }

  getDomain<T extends Domain>(name: string): T {
    const domain = this.domains.get(name);
    if (!domain) {
      throw new DomainNotLoadedError(name);
    }
    return domain as T;
  }
}

Plugin Architecture

// core$plugins/
interface DomainPlugin {
  name: string;
  version: string;
  dependencies: string[];

  initialize(kernel: ClaudeFlowKernel): Promise<void>;
  shutdown(): Promise<void>;
}

// Example: Swarm Coordination Plugin
export class SwarmCoordinationPlugin implements DomainPlugin {
  name = 'swarm-coordination';
  version = '3.0.0';
  dependencies = ['task-management', 'session-management'];

  async initialize(kernel: ClaudeFlowKernel): Promise<void> {
    const taskDomain = kernel.getDomain<TaskManagementDomain>('task-management');
    const sessionDomain = kernel.getDomain<SessionManagementDomain>('session-management');

    // Register swarm coordination services
    this.swarmCoordinator = new UnifiedSwarmCoordinator(taskDomain, sessionDomain);
    kernel.registerService('swarm-coordinator', this.swarmCoordinator);
  }
}

Domain Events & Integration

Event-Driven Communication

// core$shared$domain-events/
abstract class DomainEvent {
  public readonly eventId: string;
  public readonly aggregateId: string;
  public readonly occurredOn: Date;
  public readonly eventVersion: number;

  constructor(aggregateId: string) {
    this.eventId = crypto.randomUUID();
    this.aggregateId = aggregateId;
    this.occurredOn = new Date();
    this.eventVersion = 1;
  }
}

// Task domain events
export class TaskAssignedEvent extends DomainEvent {
  constructor(
    taskId: string,
    public readonly agentId: string,
    public readonly priority: Priority
  ) {
    super(taskId);
  }
}

export class TaskCompletedEvent extends DomainEvent {
  constructor(
    taskId: string,
    public readonly result: TaskResult,
    public readonly duration: number
  ) {
    super(taskId);
  }
}

// Event handlers
@EventHandler(TaskCompletedEvent)
export class TaskCompletedHandler {
  constructor(
    private metricsRepository: IMetricsRepository,
    private sessionService: SessionLifecycleService
  ) {}

  async handle(event: TaskCompletedEvent): Promise<void> {
    // Update metrics
    await this.metricsRepository.recordTaskCompletion(
      event.aggregateId,
      event.duration
    );

    // Update session state
    await this.sessionService.markTaskCompleted(
      event.aggregateId,
      event.result
    );
  }
}

Clean Architecture Layers

// Architecture layers
┌─────────────────────────────────────────┐
│              Presentation               │  ← CLI, API, UI
├─────────────────────────────────────────┤
│              Application                │  ← Use Cases, Commands
├─────────────────────────────────────────┤
│               Domain                    │  ← Entities, Services, Events
├─────────────────────────────────────────┤
│            Infrastructure               │  ← DB, MCP, External APIs
└─────────────────────────────────────────┘

// Dependency direction: Outside → Inside
// Domain layer has NO external dependencies

Application Layer (Use Cases)

// core$application$use-cases/
export class AssignTaskUseCase {
  constructor(
    private taskRepository: ITaskRepository,
    private agentRepository: IAgentRepository,
    private eventBus: DomainEventBus
  ) {}

  async execute(command: AssignTaskCommand): Promise<TaskResult> {
    // 1. Validate command
    await this.validateCommand(command);

    // 2. Load aggregates
    const task = await this.taskRepository.findById(command.taskId);
    const agent = await this.agentRepository.findById(command.agentId);

    // 3. Business logic (in domain)
    task.assignTo(agent);

    // 4. Persist changes
    await this.taskRepository.save(task);

    // 5. Publish domain events
    task.getUncommittedEvents().forEach(event =>
      this.eventBus.publish(event)
    );

    // 6. Return result
    return TaskResult.success(task);
  }
}

Module Configuration

Bounded Context Modules

// core$domains$task-management$module.ts
export const taskManagementModule = {
  name: 'task-management',

  entities: [
    TaskEntity,
    TaskQueueEntity
  ],

  valueObjects: [
    TaskIdVO,
    TaskStatusVO,
    PriorityVO
  ],

  services: [
    TaskSchedulingService,
    TaskValidationService
  ],

  repositories: [
    { provide: ITaskRepository, useClass: SqliteTaskRepository }
  ],

  eventHandlers: [
    TaskAssignedHandler,
    TaskCompletedHandler
  ]
};

Migration Strategy

Phase 1: Extract Domain Services

// Extract services from orchestrator.ts
const extractionPlan = {
  week1: [
    'TaskManager → task-management domain',
    'SessionManager → session-management domain'
  ],
  week2: [
    'HealthMonitor → health-monitoring domain',
    'LifecycleManager → lifecycle-management domain'
  ],
  week3: [
    'EventCoordinator → event-coordination domain',
    'Wire up domain events'
  ]
};

Phase 2: Implement Clean Interfaces

// Clean separation with dependency injection
export class TaskController {
  constructor(
    @Inject('AssignTaskUseCase') private assignTask: AssignTaskUseCase,
    @Inject('CompleteTaskUseCase') private completeTask: CompleteTaskUseCase
  ) {}

  async assign(request: AssignTaskRequest): Promise<TaskResponse> {
    const command = AssignTaskCommand.fromRequest(request);
    const result = await this.assignTask.execute(command);
    return TaskResponse.fromResult(result);
  }
}

Phase 3: Plugin System

// Enable plugin-based extensions
const pluginSystem = {
  core: ['task-management', 'session-management', 'health-monitoring'],
  optional: ['swarm-coordination', 'learning-integration', 'performance-monitoring']
};

Testing Strategy

Domain Testing (London School TDD)

// Pure domain logic testing
describe('Task Entity', () => {
  let task: TaskEntity;
  let mockAgent: jest.Mocked<AgentEntity>;

  beforeEach(() => {
    task = new TaskEntity(TaskId.create(), 'Test task');
    mockAgent = createMock<AgentEntity>();
  });

  it('should assign to agent when valid', () => {
    mockAgent.canAcceptTask.mockReturnValue(true);

    task.assignTo(mockAgent);

    expect(task.assignedAgent).toBe(mockAgent);
    expect(task.status.value).toBe('assigned');
  });

  it('should emit TaskAssignedEvent when assigned', () => {
    mockAgent.canAcceptTask.mockReturnValue(true);

    task.assignTo(mockAgent);

    const events = task.getUncommittedEvents();
    expect(events).toHaveLength(1);
    expect(events[0]).toBeInstanceOf(TaskAssignedEvent);
  });
});

Success Metrics

  • [ ] God Object Elimination: orchestrator.ts (1,440 lines) → 5 focused domains (<300 lines each)
  • [ ] Bounded Context Isolation: 100% domain independence
  • [ ] Plugin Architecture: Core + optional modules loading
  • [ ] Clean Architecture: Dependency inversion maintained
  • [ ] Event-Driven Communication: Loose coupling between domains
  • [ ] Test Coverage: >90% domain logic coverage

Related V3 Skills

  • v3-core-implementation - Implementation of DDD domains
  • v3-memory-unification - AgentDB integration within bounded contexts
  • v3-swarm-coordination - Swarm coordination as domain plugin
  • v3-performance-optimization - Performance optimization across domains

Usage Examples

Complete Domain Extraction

# Full DDD architecture implementation
Task("DDD architecture implementation",
     "Extract orchestrator into DDD domains with clean architecture",
     "core-architect")

Plugin Development

# Create domain plugin
npm run create:plugin -- --name swarm-coordination --template domain

Related skills

How it compares

Use v3 ddd architecture for structural DDD refactors in agent repos; use base-template-generator when starting new modules from scratch without decomposition work.

FAQ

What codebase does v3 ddd architecture target?

v3 ddd architecture targets claude-flow v3 agent projects in ruvnet/ruflo. It decomposes monolithic god objects into bounded contexts using Domain-Driven Design and clean architecture patterns.

What architecture patterns does v3 ddd architecture apply?

v3 ddd architecture applies bounded contexts, clean architecture layering, and a microkernel pattern to separate concerns. Output includes domain boundary maps and modular refactor guidance for testable agent code.

Is V3 Ddd Architecture safe to install?

skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.

Backend & APIsbackendintegrations

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.