The Premier Domain-Driven Design (DDD) Modeling Tool, Powered by AI

Why Use a Tool for Domain-Driven Design?

Domain-Driven Design (DDD) is a powerful method for building complex software that truly aligns with business needs. However, turning business knowledge into a well-structured, actionable domain model is a significant challenge. It requires deep collaboration, expertise, and a lot of time. This is where a specialized DDD modeling tool becomes essential.

Qlerify is an AI-powered domain-driven design tool built to solve this problem. It accelerates the entire modeling process, enabling teams to visually collaborate, define bounded contexts, and generate API-ready models from a simple text prompt. As showcased in a recent Virtual DDD Meetup by Qlerify co-founder Staffan Palopää, our tool bridges the gap between business concepts and executable code.

The session, which even drew questions from DDD creator Eric Evans himself, demonstrated how AI can generate a complete workflow, identify domain events, map out commands and aggregates, and ultimately produce a tangible domain model. This article provides a detailed, step-by-step guide to replicate that process, showing you how Qlerify can serve as your central DDD modeling tool.

Getting Started with Our DDD Modeling Tool

To follow along, log in to Qlerify or sign up for a free trial. Once logged in, create a new project, start a blank workflow, and follow this walkthrough.

Note: This guide focuses on using Qlerify as a domain-driven design tool. For a broader introduction to our features, see the Event Storming walkthrough.

Step 1: Review Card Types

Before you begin, ensure you have created a new blank workflow and have an empty canvas in front of you. In an empty swim lane, you should see three buttons: "Add start point",  "Generate workflow with AI" and "Start with MCP".

Next, open Workflow Settings by clicking the cogwheel icon (⚙️) located above the empty diagram. Navigate to the Cards tab and review the Card Type Settings:

• Use AI: Under this heading, verify that Command and Aggregate Root are selected. Additional card types are optional. For this walkthrough, we will deselect Read Model and Given-When-Then. You can read more about these specific card types in the Event Modeling guide (linked in the footer).
• Domain Model Role: Under this heading, ensure the following roles are selected in the dropdown menu for specified card types:
  
  • For the Command card type, select Command in the dropdown.
  • For the Aggregate Root card type, select Aggregate Root in the dropdown.

Step 2: Generate with AI

If you wish to change the LLM (Large Language Model), you can do so in Workflow Settings → AI. In this example, we use Claude Sonnet 5.

Close the Workflow Settings window. If your workflow is empty, the "Generate Workflow with AI" button will be visible. Click this button and select the following prompt (or enter your own):

• "A CRM process used by Salesforce"

Next, ensure the following checkboxes are checked:

• "Generate Command Attributes with AI"
• "Generate Entities with AI"

Deselect any other check boxes. Then click the "Generate Workflow" button. The generation process may take a few minutes to complete.

Once the process finishes, the LLM will have generated Domain Events, along with cards for Commands, Aggregate Roots and Entities. The Domain Events are placed on a timeline and distributed across swim lanes. Your resulting workflow should resemble the example image shown below (though variations due to the AI are expected).

Inspect Events

At this point, each step (Event) in the generated workflow should include exactly one Command card and one Aggregate Root card. Click on an Event to select it and inspect its cards in the sidebar.

The Aggregate Root card can either contain a simple text label with a descriptive name, or it can be linked to an Entity. If the card displays an Entity name within a grey, rounded element (with a dropdown icon to the right), it is linked to that Entity. If the Aggregate Root card displays a link icon (🔗) next to a text label, it is not linked to an Entity.

If not linked, you can click the link icon (🔗) and select an Entity from the dropdown list (or generate an Entity). Selecting an Entity replaces the simple text label with a link to the formally defined Entity.

Inspect Entities

Navigate to the Entities tab located under the workflow diagram area. Here you can see the generated Entities, each with a description of what it represents, and for every field its name, data type, description, whether it is a primary key or required, and example data. The AI fills all of this in when it generates - and you can edit any of it yourself.

Click + Entity to add more. You get three options: generate all missing entities based on the workflow, generate one or many entities from a description you write, or start manually with an empty entity.

Relationships are defined as data types. Give a field the data type of another Entity and choose the cardinality. In the example above, Account has a billingAddress field typed as Billing Address - a separate Entity - with a 1:1 relationship. Use 1:N for one-to-many.

TIP: If you already have a data model you want to reuse, attach it in the Generate workflow with AI dialog - it accepts .md, .txt, .pdf and image files, so a schema export or ERD works. You can also create the Entities first and then generate; the AI takes the Entities already in the workflow into account.

Inspect the Domain Model

1. Navigate to the Domain Model tab (located under the workflow diagram area).
2. Ensure no Event is selected so that all events are visible in the Domain Model view. (If an event is selected, clear the selection).
3. You can hide Read Models for a more focused view by deselecting "Show read models".
4. Under the Aggregate Root heading, you will see boxes (with yellow borders) containing the Aggregate Roots. If the AI generation was successfully completed the Aggregate Root cards should be linked to Entities (as mentioned earlier in this article).

If more than one Command operates on one Aggregate Root, you will see Commands (boxes with blue borders) grouped around the Aggregate Roots. If you need to move a single Command to a different Aggregate Root, first select the corresponding Event, then change the Aggregate Root specifically for that Command (in the box with yellow borders).

Step 3: Review the Events

Now it's time to review each Event and its details. Iterate through Steps 3 - 5 for each event. It is recommended to perform this review collaboratively with Domain Experts to validate assumptions and refine the model.

Let's start by selecting the first event: "Lead Created". Inspect the workflow and the Domain Model. Ask the following questions and refine the model based on the answers.

1. Event Name & Actor:

• Is it accurate that Sales Reps create Leads? (Or is the actor different?)
• Does the term "Lead Created" reflect the actual language and terminology used within the business domain (the Ubiquitous Language)?
• Or is a different term or phrasing used, such as "Account Manager added Prospect"?
• Action: If necessary, update the event name to accurately reflect the business process and language. Consider updating the swim lane (actor) if needed

2. Aggregate Root & Entity:

• What is the core concept or Entity being created or modified by this Event?
• Is "Lead" the correct term (Ubiquitous Language) for this core concept?
• Should Leads be managed as distinct records (e.g., stored in a dedicated database table or collection)?
• Should Leads have their own lifecycle – meaning they can be created, updated, and potentially deleted independently of other Entities? Does this Event represent the start of that lifecycle?‍
• Action: Discuss and validate this concept with Domain Experts. Confirm that the correct Aggregate Root is linked to this event in the Domain Model. You might need to rename the linked Entity, select a different existing Entity, or even generate/create a new Entity via the Entities tab or the "Create a new entity with AI" option discussed in Step 4.
  

Note: Ensure the event you are reviewing represents a genuine state-changing action (like a create, update, or delete) on the identified Aggregate Root / Entity. If the event describes a query, a read operation, or something that doesn't fundamentally change the state of the core entity, it might not be a true Domain Event for this workflow. Consider removing it from this primary sequence for now (e.g., by deleting it or moving it to a separate analysis area/branch in Qlerify) and potentially modeling it differently (perhaps as a Read Model interaction, discussed later).

‍

Step 4: Review the Command Details

Now, let's focus on the Command associated with the event you are reviewing (the box with blue borders in the Domain Model). We need to define the data fields (parameters) required to execute this Command.

What information does a Sales Rep need to provide when creating a Lead? Open the sidebar in Qlerify and navigate to the "Data Fields" tab. This tab shows a simple mockup of the input form based on the Command.

Are the fields correct? Are any fields missing? Add, remove, or reorder fields in the Domain Model, directly inside the blue Command box, not in the mockup.

‍

Qlerify supports five main shapes of Command fields, corresponding to different data structures. All of them are controlled by just three settings:

• Data types are defined on the Entity, not on the Command. A field on an Entity is either a primitive (String, Number, Boolean) or an Object. Object is the only relation type: when you pick it, you also select which Entity the field points to.
• Every Object field has a cardinality: 1:1 (one related item) or 1:N (a list of related items).
• On the Command, a field linked to an Entity either carries nested fields or it doesn't. Nested fields mean the Command writes data into that related Entity, so the Entity belongs inside the Aggregate boundary for this Command. No nested fields mean the Command only points at an existing item, and the Entity stays outside the boundary.

1. Single Input Fields (Primitive Types)

These represent single values like numbers, dates, text, or booleans. In the UI mockup they are shown as plain fields with labels and example data.

• Example: For creating a Lead, we might have fields like "leadName", eEmail", "contactPhone", etc.
• How to Add: Simply add a new field using the plus icon (+) at the bottom left corner of the blue Command box (displayed on hover).
• Relation to Entity: Often, each Command field correspond directly to a field on a target Entity. Qlerify shows a warning (e.g., a yellow or red triangle ⚠️) if a Command field does not have a matching field (by name and type) on one of the Entities inside the Aggregate boundary (more about this later).
• Important: Not every Command field must map directly to an Entity field. Commands orchestrate actions and might take inputs used for logic or side effects without being stored directly on an Entity. We are modeling more than just simple CRUD operations.
• Edit Entity: You can modify Entities by clicking the edit icon (pen symbol 🖊️ at the bottom left in the box with yellow borders), or access it via the Entities tab.

‍
2. Single Reference to a Related Entity

A reference is used when the Command needs to point to another Entity without changing it. The referenced Entity stays outside the Aggregate boundary for this Command.

In the UI mockup shown as a single select drop down.

• Example: the Lead Source should not be a free text field, but instead picked from a predefined list of lead sources (e.g. 'Website', 'Referral'). The Sales Rep selects one lead source from the list, without modifying the list.
• Naming: call the field leadSource - not "leadSourceId". The model only says "this Command needs a Lead Source"; whether the reference is later implemented as an id, a foreign key or something else is a technical decision that doesn't belong in the domain model.

• Modeling Steps:
  1. Link Entity: on the Command, click the three-dots menu next to the "leadSource" field, then Select Entity. An Entity named "Lead Source" doesn't exist yet, so click "Create a new entity with AI", name it "Lead Source" and create it, then select it. A chip with the entity name now appears next to the field.
  2. Set Cardinality: at the bottom of the same menu, make sure the cardinality is 1:1 (the toggle is enabled once an entity is linked).
  3. This is the key step: leaving the field without sub-fields is what makes it a pure reference - the Command needs a Lead Source but does not modify one. Do not add nested fields: This is the key step: leaving the field without sub-fields is what makes it a pure reference - the Command needs a Lead Source but does not modify one.
  4. Mirror on the Entity: edit the Lead Entity (pen icon). On its "leadSource" field choose Change data type → Object → Select Entity → "Lead Source", and set cardinality to 1:1. (If the field is missing or linked differently, Qlerify warns (⚠️) on the Command field and offers a one-click fix.)
  5. Result: the Data Fields mockup shows a dropdown of Lead Sources, populated from the Lead Source Entity's example data. You can even pick one - the selection is saved as example data. The "Lead Source" Entity itself remains outside the Lead Aggregate boundary.

Note: What about things outside your application? Sometimes a Command needs to point at something that doesn't live in your application at all. Say the Lead was generated by an ad campaign that is managed in an external marketing platform. Don't create an Entity for it, and don't use an Object relation - there is nothing in your model to point at. Instead, keep a primitive String field holding the external identifier, and name it with an Id suffix: campaignId. You don't know the full structure of the campaign object in the external platform, and you don't need to - the id is all you store. Notice the contrast with Lead Source on the same Command: Lead Source is an Entity in your model, so the field is a real reference named after the Entity (leadSource). The Id suffix is reserved for external identifiers only - inside your own model it's never "leadSourceId".
‍

3. Multiple References to Related Entities

Similar to a single reference, but linking to multiple instances of another Entity. In the UI mockup shown as a drop down with checkboxes.

• Example: If a Sales Rep should be able to select multiple Lead Sources for a single Lead.
• Modeling Steps: Follow the steps for a Single Reference, but when editing the "leadSource" field on the Command, change the cardinality from 1:1 to 1:N (one-to-many). In most cases you would also change the cardinality on the Entity.
• Result: The mockup shows a multi-select control instead of a single dropdown.

4. Collection of Entities (Nested items within Aggregate Boundary)

This type is used for collections of related entities that reside inside the Aggregate boundary for this command. In the UI mockup it is shown as a list of items, like order rows, where items can be added, edited and removed.

• Example: Multiple comments or meeting notes to be included when creating a Lead. Each note might have text, date, author.
• Modeling Steps:
  1. Define Collection on the Entity: Click on the pen icon (🖊️) at the bottom left of the entity to open the edit dialog. Add a field named "lLead Notes". Generate a new entity with AI called "Lead Note" and connect it to this field. Set the cardinality to 1:N.
  2. Add Nested Fields on Command: On the Command "Create Lead", open the field selector (at the bottom inside the blue Command box). Add nested fields representing the data needed for each Lead Note by expanding leadNotes and clicking the checkboxes for fields like: noteText, createdBy, createdAt (the field names will usually differ).
• Result: The lead notes become a part of the same Command that creates the lead. Thus this collection is within the Lead Aggregate boundary. The UI mockup will show the notes as a list of items.

5. Single nested Entity (Item within Aggregate Boundary)

This represents a single related entity (with its own fields) that is located inside the Aggregate boundary for this command. In the UI mockup shown as a sub form.

• Example: Storing an address (with street, city, state, postalCode, country) as part of the Lead Entity.
• Modeling Steps:
  1. Define Entity: Click on the pen icon (🖊️) at the bottom left of the Entity "Lead" to open the edit dialog. Add a field named "address". Click on Select Entity for the new Address field. Generate and connect a new Entity named "Address" to this field. Set the cardinality to 1:1.
  2. Add Nested Fields: On the Command card, open the field selector. Add nested fields for street, city, state, postalCode, country.

• Result: Just like collections, the Address fields will be located inside the Aggregate boundary. The UI mockup will show the address fields grouped together.

Now we can review the Aggregate boundary, for this Command, and and the Aggregate which is displayed inside the boundary.

• References (like "leadSource") point outside the boundary. The Command field is linked to an Entity but carries no nested fields, so the referenced Entity is not part of the Aggregate.
• Collections (like "Lead Notes") and Embedded Objects (like "Address") -fields where the Command carries nested data - reside inside the boundary for this Command.

Note: Aggregate boundaries are dynamic. The boundary visualized for a specific Command/Event shows only what's directly manipulated or included by that operation. When viewing the overall Domain Model without filtering by a specific Event, Qlerify typically shows an accumulated view, including all Entities that fall within the Aggregate boundary for any of its associated Commands.

‍

Step 5: Define Read Models

The next step is to identify Read Models. Read Models represent the information (or views of data) an actor needs before executing a specific command. Think of them as queries that fetch relevant context to support decision-making or populate a user interface.

Not every event/command necessarily needs a preceding Read Model fetched from the system. For instance, the "Lead Created" event might be triggered externally (e.g., by a phone call) without the user first querying data within an application.

Let's now use a different event from our example workflow: "Lead converted to opportunity". Before a Sales Rep converts a Lead to an Opportunity, what data should the system present to them?

1. In the workflow diagram, select the event "Lead converteed to opportunity".
2. Navigate to the Domain Model tab.
3. Ensure the checkbox "Show read models" is checked.

Now, let's define the necessary Read Models for this event:

Example 1: Listing Leads Available for Conversion

To convert a Lead, the Sales Rep first needs to select one. Let's define a Read Model to list relevant Leads.

1. Click the "+Read Model" button associated with the selected event.(Located under the Read Model heading the left side of the Domain Model tab.)
2. Select Entity: Choose the Lead Entity .‍
3. Select Fields: Open the field selector (visible at the bottom of the green Read Model box on hover) and check the fields relevant for display in the list, such as "leadName", "contactEmail", "companyName", and "status".‍
4. Add Filter: Add a filter icon on the field "status" using the menu (three dots ⋮) next to the "status" field. This indicates to the model which fields we need to be able to filter on. By dragging all fields that should have filter functionality to the top you can make the model easier to read.‍
5. Query Type: Leave the query type as the default: "List", as we expect multiple results, and not just "Single Item".
6. Update the description: Describe the query using natural language in the text field above the list of fields: "List of open Leads available for conversion to an Opportunity. Filtered on status open."

Example 2: Listing Related Opportunities for Context

When selecting a Lead to convert, it might be helpful for the Sales Rep to also see if any Opportunities already exist for the same Company. Let's add a second Read Model for this.

1. Click the "+" icon visible below the previously created Read Model (on hover), to add another Read Model for the same event.
2. Select Entity: Choose the Opportunity.
3. Select Fields: Open the field selector and choose the fields to display, such as "opportunityName", and "estimatedValue".
4. Add Company as a new entity: On the entity "Opportunity", let's add "company" as a related entity. Open the entity Opportunity, add a field company. Now use the menu (three dots ⋮) next to the company field to generate a new entity "Company" and connect it to the field. Using the same menu, set it as a reference and cardinality 1:1. (Just like we did with leadSource earlier.)
5. Add Contextual Filter: Back to our new Read Model. We want to filter the existing Opportunities based on the companyName of the Lead we are about to convert.
   • On the Read Model, open the field selector again and expand the company sub fields by clicking company. Include companyId and companyName field in the query.
   • Close the field selector, back on the Read Model (green box) mark companyName as a filter using the menu (three dots ⋮) next to the field.
   • If we don't have company name available on the Lead then now we can see that we probably should add it.
6. Update Description: We will use the description (the textbox inside the green Read Model box) to explain with natural language how we want the filter to work. Add a clear description, for example: "List of existing open Opportunities with a company name similar company name on the Lead."
7. Query Type: Ensure the query type is set to "List".

Conclusion:

By defining Read Models like these, you specify the data needed before commands are executed. This helps design more user-friendly interfaces and ensures actors have the necessary context, improving the efficiency and effectiveness of the system.

‍

Step 6: Define Bounded Contexts

A core concept in Domain-Driven Design (DDD) is the Bounded Context. We define Bounded Contexts to divide a large system into more manageable, logically consistent parts, helping to clarify scope, ownership, and the meaning of model elements within each context.

If you generated the workflow with AI, this step is already half done: during generation, Qlerify assigns every Entity to a Bounded Context. The AI groups aggregates that change together and belong to the same subdomain, and keeps value objects together with the aggregate root that owns them. So instead of assigning contexts from scratch, your job is to review the proposed grouping and adjust it to match your intended architecture.

1. Navigate back to the Domain Model tab and look how the Entities are grouped.
2. Ask yourself: does this grouping match how you plan to split the system into services and teams? The AI proposes a reasonable starting point, but it cannot know your organization's plans.
3. To move an Entity, click the Select bounded context button on the entity and pick a different context - or create a new one.
4. In our example, let's say we are building a new Microservice for handling Leads. So we want the Lead entity in its own Bounded Context named "Lead Management", together with the entities Lead Note and Address.
5. Opportunity and Quote will reside in the CRM context, so these entities belong in a Bounded Context named "CRM".

Observing the Results:

After assigning contexts, the Domain Model view should visually reflect this structure:

• Aggregates grouped together by their assigned Bounded Context.
• Commands visible next to their respective Aggregates.

Context Map:

Qlerify also provides a part of a Context Map view. This view helps visualize the relationships and dependencies between different Bounded Contexts.

When viewing a single Bounded Context you will see integration points – places where commands in the current context trigger updates on Entities in other Bounded Contexts. These integration points are highlighted with the label "Integration with other bounded contexts".

Step 7: Generating Code from the Domain Model

You have now defined a comprehensive Domain Model within Qlerify, encompassing:

• Domain Events
• Entities (including Aggregate Roots, Collections, and Embedded Objects)
• Commands (with detailed fields and references)
• Read Models (queries for contextual data)
• Roles (actors/swim lanes)
• Bounded Contexts

This Domain Model serves as powerful, living system documentation and provides a solid foundation for development, provided that it accurately reflects your actual domain logic. It's crucial to iterate on this model and keep it up-to-date as the understanding of the domain evolves or the system changes.

Now comes the most exciting part: turning the Domain Model into working code.

Qlerify doesn't generate the code inside the app. Instead, your model plugs directly into the AI coding agent you already use - Claude Code, Cursor, and other MCP-compatible tools - through the Qlerify MCP server and its companion plugin. Your coding agent reads the Domain Model straight from Qlerify and generates the application with full knowledge of your Entities, Commands, Read Models, Domain Events, and Bounded Contexts.

This generation process is typically performed per Bounded Context, reinforcing the modularity of your design.

The specific steps for initiating and configuring AI-assisted code generation are described in detail in a separate guide: the "Spec-Driven Development (SDD) Tool" article. You can find a link to this article in the footer of the page.

‍