Project — Agentic DDD Platform

• 24 March 2026
• System Design,
• DDD,
• LLM,
• AI Agents,
• Go,
• TL3

This Post is still Work-In-Progress (:

Before diving deeper into the Agentic Workflow space, let's work on a project to have some direction.

Domain Driven Design (DDD) has a large influence on how I think about systems, but is hard to apply effectively, especially when working in teams within an organization who do not know much about it.

Now that Agentic Workflows are becoming the norm, and LLMs can heavily abstract away the mechanics of applying DDD effectively, this seems like a good project to work on.

Agentic DDD Platform

The DDD methodology provides a framework from converting formal business language into working systems. By having visibility into actual business workflows, an engineer can effectively implement just enough features to meet business objectives, hence reducing the overall complexity, and achieving maximum impact or value creation.

The goal of this platform is to translate a business from a user's point-of-view, described by a business domain expert, and construct deployable technical artifacts to create a minimal working system to meet those business needs.

The inputs will be from 2 personas: (1) Domain Expert; (2) Software Engineer. The domain expert will describe the user interactions with the system, and the software engineer will enhance the intermediary artifacts generated by the platform from the domain expert's input. The platform will support multiple iterations between the domain expert and the software engineer before generating outputs. This output construct will be in the form of multiple technical artifacts like code, binaries, containers, infrastructure-as-code descriptions, etc, which the software engineer will use to deploy the system.

The value of this platform is in the iterative collaboration aspect between technical and non-technical folks. When building a large system, it is largely a discovery process where the constraints may not be known upfront; i.e. its not possible to fully describe an entire system in a few prompts or a markdown file. By building iteratively, the team can create checkpoints at various points in the project lifecycle and branch out when an idea or experiment does not work.

Table of Contents

1. DDD Strategic Design
2. DDD Tactical Design
3. Non-Functional Requirements
4. API Endpoints
5. Capacity Estimation
6. Cost Estimation
7. System Architecture

System Design

DDD Strategic Design

The domain of the Agentic DDD Platform is as follows:

DDD Tactical Design

Collaboration Workflow

sequenceDiagram
  actor user as Expert / Engineer / AI Agent
  participant docServer as Document Server
  participant Database@{ "type" : "database" }
  docServer->>user: Server-Sent-Events connection
  user ->> docServer: POST: Updates document
  docServer -->> user: 200
  docServer ->> Database: Periodically saves document to DB
  Database -->> docServer: 200

Prompt Workflow

sequenceDiagram
  actor expert as Expert / Engineer
  participant promptServer as Prompt Server
  participant Database@{ "type" : "database" }
  participant agent as Agent
  participant llm as LLM Server
  participant docServer as Document Server
  expert->>promptServer: POST: prompt
request
  promptServer->>promptServer: Validate prompt
  promptServer->>Database: insert prompt request
  Database-->>promptServer: success
  promptServer-->>expert: 200
  agent->>Database: POLL: Read prompt request
  Database-->>agent: success
  loop till no more prompts
    agent->>llm: Prompt the LLM
    llm-->>agent: LLM response
    alt new prompt
      agent->>Database: insert prompt request
      Database-->>agent: success
    end
  end
  agent->>Database: Create prompt response
  Database-->>agent: success
  agent->>docServer: POST: Updates document
  docServer-->>agent: 200
  expert->>promptServer: GET: prompt
response
  promptServer->>Database: Read prompt response
  Database-->>promptServer: success
  promptServer-->>expert: 200

Artifact Generation Workflow

sequenceDiagram
  actor engineer as Engineer
  participant artifactServer as Artifact Server
  participant Database@{ "type" : "database" }
  participant agent as Agent
  participant llm as LLM Server
  engineer->>artifactServer: POST: Generate
Artifacts
  artifactServer->>Database: insert GenerateArtifacts request
  Database-->>artifactServer: success
  agent->>Database: POLL: Read GenerateArtifacts request
  Database-->>agent: success
  agent->>Database: Read current Document state
  Database-->>agent: success
  agent->>llm: Convert Document to structured JSONL
  llm-->>agent: JSONL responses
  loop till no more JSONL
    agent->>agent: Generate Technical Artifact based on current JSONL
    agent->>Database: Save Artifact into DB
    Database-->>agent: success
  end
  agent->>Database: Create GenerateArtifacts response
  Database-->>agent: success
  engineer->>artifactServer: GET: GenerateArtifacts
response
  artifactServer->>Database: Read GenerateArtifacts response
  Database-->>artifactServer: success
  artifactServer->>artifactServer: Compress Artifacts into a single object
  artifactServer-->>engineer: Compressed Artifacts download

Non-Functional Requirements

TBD

API Endpoints

TBD

Capacity Estimation

TBD

Cost Estimation

TBD

System Architecture

TBD

• ← Previous
  Context Engineering