1. Knowing Nothing: Where to Begin

Use this workshop-driven method when you need to understand an unfamiliar business domain before you model it in **MDriven Designer**.

When you begin a new system, the first problem is often not how to implement it. The problem is finding out what people actually do, what information they use, and what rules control their work. Existing documentation and IT staff can help, but they are not a replacement for the people who perform the work every day.

This page gives you a path from an initial conversation to process diagrams, class diagrams, state diagrams, and eventually ViewModels.

> **Example domain:** A small bakery sells bread to customers. The examples below use this domain to show the method end to end.

1. 1. Start with the people who do the work

Invite a representative group of domain people to a workshop. A **domain person** is someone who performs, receives, supports, or is directly affected by the work you are investigating.

Include people with different perspectives. For the bakery example, this may include a shop assistant, baker, purchaser, delivery driver, and manager. Do not invite only managers or IT staff: they may describe the intended process rather than the real one.

The workshop has three outputs:

| Output | Definition | Bakery example | |---|---|---| | **Trigger** | A person, organization, or event that starts or affects work. | A customer enters the shop; a supplier delivers flour. | | **Goal** | The outcome that a person or organization wants. | A customer wants to buy a loaf of bread. | | **Process** | The important business steps used to reach a goal after a trigger. | Select bread, hand it to the customer, receive payment. |

Keep the language used by the domain group. You can improve names later, but changing their words too early can hide important distinctions.

1. 1. 1. Find the triggers

Ask the group who has an interest in their work. Ask both directions of each question:

- Who calls you? Who do you call? - Who emails you? Who do you email? - Who visits you? Who do you visit? - Who delivers something to you? Who do you deliver to? - Who sends something to you? Who do you send something to? - Who buys from you? Who do you buy from?

Record each distinct answer as a trigger. A trigger is not limited to a person; an event can also start work. For example, “a delivery arrives” is a useful trigger when the work begins on arrival rather than with a particular named individual.

1. 1. 1. Example: trigger list

| Trigger | Direction | What it suggests | |---|---|---| | Customer | Customer contacts the bakery | A sales process may exist. | | Supplier | Supplier delivers flour | A receiving or stock process may exist. | | Shop assistant | Assistant contacts the baker | A replenishment process may exist. |

Avoid prematurely naming database classes at this stage. “Customer” is a participant in work; later investigation determines what information about a customer the model needs.

1. 1. 2. Find the goal behind each trigger

For every trigger, ask what that person or organization is trying to achieve. Ask why the interaction happens, not only what happens.

For example:

- **Trigger:** Customer - **Goal:** Buy a loaf of bread

The same trigger can have several goals. A customer may want to buy bread, ask about ingredients, or complain about an order. Treat these as separate goals when the work and information differ.

Write goals as outcomes. “Take payment” is usually a step in a process, while “buy a loaf of bread” is the customer’s goal.

1. 1. 1. Example: trigger-to-goal list

| Trigger | Goal | |---|---| | Customer | Buy a loaf of bread | | Customer | Ask about ingredients | | Supplier | Deliver flour | | Shop assistant | Replenish bread on the shelf |

1. 1. 3. Turn triggers and goals into processes

Split the workshop into small groups. Give each group a meaningful trigger-and-goal combination and ask them to describe the central steps needed to reach the goal.

Aim for about five important steps. This is an overview, not a work instruction. Remove steps that do not help explain the business outcome.

If the group cannot start, ask for one obvious step and work outward:

1. Ask: “What must happen for the goal to be achieved?” 2. Ask: “What happens immediately before that?” 3. Ask: “What happens immediately after that?” 4. Continue until the group has the essential flow.

1. 1. 1. Example: customer buys bread

For the trigger **Customer** and the goal **Buy a loaf of bread**, the group may identify these steps:

1. Find the requested bread. 2. Fetch the bread from the shelf. 3. Hand the bread to the customer. 4. Receive payment. 5. Complete the sale.

“Hand the bread to the customer” is a useful starting point because people can explain the necessary work before and after it. The result is a business-level process that describes what happens without yet deciding how software will implement it.

1. 1. 4. Review, remove, and connect processes

Bring the groups back together and compare their processes.

1. Remove duplicate processes. 2. Remove steps that do not contribute to the stated goal. 3. Identify steps that need their own detailed process. 4. Ask the domain group to validate the resulting process names and sequence.

A process can detail a step in another process. In the bakery example, **Complete the sale** may be a step in **Customer buys bread**, while **Receive payment** may require its own detailed process if cash, card, refunds, or failed payments are important to the business.

This creates a hierarchy: high-level processes explain the business at a glance, and detailed processes explain selected steps. Maintain this hierarchy in the diagram structure so readers can navigate from a broad process to its details.

1. 1. Why domain people are required

Do not rely only on existing documentation or the company’s IT team.

There are two reasons:

1. **The current description may be wrong or incomplete.** Documentation can describe an old process, and IT systems can reflect historical decisions rather than current business needs. 2. **Participation builds trust.** The people whose work will change need to see that the system is based on their reality. Involving them early also gives you people who can validate the model as it evolves.

Use existing documentation as input to workshop questions, not as proof that the documented process is correct.

1. 1. Move from processes to the information model

After you understand what happens, identify the information needed for each process. Create a small **class diagram** for each process. A class diagram describes information classes, their attributes, and their relationships.

In MDriven Designer, class diagrams are part of the model. Keep each process-focused diagram small enough to read. You do not need to place the entire domain model on every diagram.

For **Customer buys bread**, the information discussion may identify:

| Process question | Information the model may need | |---|---| | What is being sold? | Bread or product information. | | What is the transaction? | A sale. | | How was it paid? | Payment information. | | Is a buyer identity required? | Customer information, if the business needs it. |

This does not mean every bakery needs all four classes. Ask the domain group what the process requires. For example, an anonymous counter sale may not require a stored Customer class, while a pre-order process may.

Use MDriven Designer’s diagram and repository structure to keep related diagrams discoverable. The Designer overview documentation shows that diagrams appear in the overview and repository tree, and that you can add a class diagram and name it through the Object Inspector. For guidance on working with Designer itself, see Documentation:MDriven designer overview Part 1.

1. 1. Add the business rules with state diagrams

A process says what work occurs. A class diagram says what information is involved. You also need to capture the rules that control an object over time.

Use a **state diagram** when an object has a lifecycle with meaningful states and allowed transitions. For example, a Sale might move through these states:

```text Started → Paid → Completed ```

The important rule is not the drawing alone; it is the allowed movement. If a sale must be paid before it is completed, model that rule rather than leaving it only in meeting notes or scattering it through handwritten code.

MDriven Designer supports state machine diagrams for modelling entity lifecycles, and MDriven supports declarative business logic through **OCL** (Object Constraint Language). OCL is the expression language used to define constraints and derived logic in the model. See Documentation:Designer for state machines and modelling topics, and Documentation:How does MDriven work for the role of OCL and declarative rules.

1. 1. Create ViewModels after the process is understood

Once the process, information, and rules are clear, decide how users need to work with them.

A **ViewModel** defines the data and behavior presented for a specific user task. It does not replace the domain model; it shapes model information for a use case.

For example, a **Sell bread** ViewModel may show the selected bread, quantity, total, and payment action. A phone-oriented ViewModel may show fewer attributes and navigations than a desktop-oriented one because the user task is narrower.

Do not start with a ViewModel when you do not yet understand the process. First establish:

1. Who starts the work. 2. What goal they want to achieve. 3. Which business steps achieve it. 4. Which information those steps require. 5. Which lifecycle rules control that information.

Then create a ViewModel that supports the validated process. For more on ViewModels and UI modelling, see Documentation:Designer.

1. 1. A repeatable checklist

Use this checklist for each unfamiliar domain area:

1. Gather representative domain people. 2. List the people, organizations, and events that trigger work. 3. Identify the goal behind each trigger. 4. Create a short, outcome-focused process for each meaningful trigger-and-goal combination. 5. Validate and organize processes into a hierarchy of overview and detailed processes. 6. Create a focused class diagram for each process. 7. Add state diagrams and OCL constraints where lifecycle and business rules must be explicit. 8. Create ViewModels for the validated user tasks. 9. Return to the domain group whenever a process or rule needs clarification.

1. 1. What you have when you finish

You should now have a navigable explanation of the domain:

- Process diagrams explain **what happens**. - Class diagrams explain **what information is involved**. - State diagrams and OCL constraints explain **what rules control change**. - ViewModels explain **how a user performs a specific task**.

This structure lets business-facing team members and developers work from the same model. MDriven Designer uses models as the basis for executable applications, so the model can continue from discovery into implementation rather than becoming disconnected documentation. For an overview of that model-driven approach, see Training:What is MDriven and Documentation:How does MDriven work.

For guidance on balancing an ideal model with the constraints of an existing business and system, see Reality and the Theoretical Best Model.