If you’re new to model-driven development, you’ve probably heard a lot of theory. But let’s be honest—the absolute fastest way to get it is to stop talking and build something real.

In this quick tutorial, we’re going to spin up a lightweight Team Task Planner using MDriven Designer. It’s going to have projects, tasks, members, progress tracking, and automated business logic.

And yes, we’ll do it in about 15 minutes.

The goal here isn’t just to build another boilerplate task app. It’s to experience a completely different way of thinking about software—where the model isn't just a diagram on a whiteboard, the model is the application.

What You’ll Build

By the time you're done, you’ll have a fully functional application running in the browser that lets you:

• Create projects and manage team members.
• Add, assign, and track tasks.
• Calculate project progress completely automatically.
• Enforce real-time validation rules.

Most importantly, you’ll see how MDriven handles the heavy lifting, generating a working system directly from your model without you writing a single line of traditional database or UI code.

Why This Tutorial Matters (The Death of the Multi-Layer Grind)

Traditional development usually feels like a game of telephone across multiple layers:

1. You design a database schema.
2. You map it to an ORM in your backend logic.
3. You expose it via API endpoints.
4. You consume it in the UI layer.
5. Then you write validation code... twice (once in the frontend for UX, once in the backend for security).

Change one requirement, and you're updating five different files across three different repositories. It's a lot of frustration.

With MDriven, we collapse all of that. Structure, relationships, business logic, and UI validation start—and stay—in one place: the model.

Step 1 — Create the Domain Model

Everything in our world starts with the domain model. Open up MDriven Designer and let's map out our reality. We need four core classes: Team, Project, Task, and Member.

Now, let's draw the associations to connect them:

• A Team has many Projects.
• A Project has many Tasks.
• A Task can be assigned to a Member.

MDriven Mindset Note: At this exact moment, you haven't just drawn a pretty picture; you have already defined the structural foundation and database schema of your system.

Step 2 — Add Attributes

An empty class isn't very useful, so let's give our objects some state. Add the following attributes to your classes:

• Project
  • Name : String
  • Deadline : Date
• Task
  • Title : String
  • IsCompleted : Boolean
  • Priority : Integer
• Member
  • Name : String
  • Email : String

As you add these, the application evolves alongside it. No migration scripts required.

Step 3 — Add Business Logic with OCL

This is where model-driven development gets incredibly satisfying. Instead of writing controller code or database triggers to calculate things, we use Object Constraint Language (OCL) right inside the model.

Let's say we want our Project class to know how many tasks it has. We can add a derived attribute called TotalTasks and define it with a simple OCL expression:

self.tasks->size

What about counting only the completed tasks? Let's add CompletedTasks:

self.tasks->select(IsCompleted)->size

Now, let's combine them to calculate the overall project progress percentage. Add a derived attribute named Progress (Integer) and give it this logic:

<if self.TotalTasks = 0 then
  0
else
  (self.CompletedTasks * 100) / self.TotalTasks
endif

No event listeners. No manual state management. The model itself ensures that the moment a task's IsCompleted flag flips, the project's progress recalculates instantly.

Step 4 — Run the Application

Let’s see the magic in action. Hit the prototyping button or launch your model using MDriven Turnkey.

Boom. Immediately, you have a working web application with:

• Main menu navigation.
• CRUD forms for your classes.
• Data grids and search lists.
• Automatic data persistence.

Go ahead—add a team, throw in a couple of projects, create some tasks, and check the "IsCompleted" box on a few of them. Watch the progress percentage update in real time.

Hmm—got you thinking, right? This is usually the exact moment when the lightbulb goes off for new users: “The model isn't just describing the app... it really is driving it.”

Step 5 — Add Validation Rules

Before we wrap up, let's make sure users can't abuse our task priorities. We want priorities to be strictly between 1 and 5.

Instead of writing JavaScript validation on the input field and duplicating C# code on the server, we add a Constraint directly to the Priority attribute in the Task class:

self.Priority >= 1 and self.Priority <= 5

If a user tries to enter a priority of 6, the system automatically rejects it and displays a validation warning. Because validation is baked into the core domain, it applies everywhere—whether data comes from a UI form, an API call, or an import script.

The Bigger Picture

Obviously, a task planner is a modest example. But the exact same mechanism you just used scales to massive enterprise landscapes—think workflow platforms, custom ERPs, complex logistics systems, and CRM tools.

The secret remains the same: instead of maintaining disconnected layers of code, your structure, logic, and rules stay unified in an executable model. What used to be hard becomes easy.

Final Thoughts

In just 15 minutes, you've successfully built a relational data structure, injected executable business logic, enforced strict validation rules, and spun up a functional web app.

If this is your first time playing with MDriven, you’ve just witnessed its ultimate superpower: you build the business domain once, and let the platform handle the repetitive infrastructure chore.

So, what are you going to model next? Let us know in the comments or hop over to our forums to share what you're working on!