Getting Started

Use this guide when you want to turn a business process, product idea, or legacy workflow into a Code Genie model that can be reviewed, generated, and hosted.

The Short Version

  1. Create a canvas for one product, process, or bounded context.
  2. Add domain events first: the meaningful things that happen in the business.
  3. Add commands before the events: the decisions or actions that try to make those events happen.
  4. Add aggregates where business rules must be protected.
  5. Add policies for follow-up behaviour, such as sending notifications, creating tasks, or starting another command.
  6. Add read models and queries for the information users need to make decisions.
  7. Group related flows into bounded contexts.
  8. Run model review, fix warnings, generate code, and optionally deploy to SAAScade Cloud.

First Steps

Begin with quick, concrete examples in Tutorials.

  • Hello World — learn the basic generation loop with a tiny model.
  • TODO Example — explore CRUD plus simple workflow behavior.

Who Should Be Involved

Code Genie works best when the canvas becomes a shared language between people who understand the business and people who will operate or extend the software.

  • Product managers define outcomes, user journeys, acceptance language, and priorities.
  • Domain experts clarify the real business rules, exceptions, vocabulary, and timing.
  • Software architects shape bounded contexts, integrations, deployment boundaries, and technical trade-offs.
  • Developers refine commands, aggregates, read models, validations, and generation settings.
  • Operations and support teams identify audit, monitoring, manual intervention, and recovery needs.

Start With Events

A domain event is phrased in the past tense because it records something that has happened: Order Placed, Payment Authorized, Refund Requested, Appointment Rescheduled. Events are usually the easiest place for business people to begin because they describe observable facts rather than technical structure.

Do not worry about perfect order at first. Place events roughly from left to right as a timeline, then move them as the story becomes clearer. The early goal is shared understanding, not tidy architecture.

Add Intent With Commands

A command is an attempt to change the system. It is usually named as an imperative verb phrase: Place Order, Approve Claim, Schedule Appointment, Reserve Inventory. Commands belong before the event or events they may produce.

Prefer commands that describe user intent over field updates. Approve Claim is stronger than Set Claim Status To Approved because it lets the model capture who can approve, when approval is allowed, and what happens next.

Protect Rules With Aggregates

An aggregate is the part of the domain that decides whether a command is valid and produces events when the decision succeeds. For example, an Order aggregate might decide whether an order can be cancelled, and a Policy aggregate in an insurance domain might decide whether a claim can be opened.

Aggregates are not database tables. They are consistency boundaries. Use them when the business has rules that must be true together.

Describe Follow-Up Behaviour

Policies react to events. They are useful when the model needs to say, “when this happens, do that.” For example, when Order Paid happens, a policy might trigger Reserve Inventory. When Subscription Payment Failed happens, a policy might trigger Start Dunning Sequence.

Policies are where workflows become visible. They reduce hidden logic because everyone can see why the next command exists.

Add Information For Decisions

Read models and queries describe what users, policies, and external systems need to know. They do not change the system. They answer questions such as “which orders are waiting for approval?” or “what is the customer’s current credit exposure?”

Good read models make generated applications feel natural because screens and APIs are based on the questions users actually ask.

When CRUD Is Enough

Code Genie can design CRUD-style systems such as a supplier directory, employee skills catalogue, or product reference database. Use CRUD when the work is mostly create, read, update, and delete around simple records.

Use deeper DDD modelling when behaviour matters: approvals, scheduling, fulfilment, billing, claims, allocation, compliance, risk, lifecycle rules, cross-team workflows, or anything where “just update the row” hides real business decisions.

Ready To Generate

Before generation, review the model for missing owners, ambiguous names, disconnected events, oversized aggregates, and policies with unclear triggers. Code Genie can generate a stronger system when the canvas explains what the business means, not only what data exists.