You can use MDriven to define an application's domain model first, execute that model, and derive database, user-interface, and code artifacts from it; this guide is for developers deciding how to work model-first with MDriven.

What model-driven development means in MDriven

Model-driven development (MDD) puts the model at the center of development. The model defines the information structure and behavior of the application. When requirements change, change the model first, then update the artifacts derived from it.

For example, an order-management application may start with these concepts:

• Customer with a name and contact details.
• Order with an order date and status.
• OrderLine with a quantity.
• An association showing that a customer places orders and an order contains order lines.

Instead of beginning with database tables and CRUD screens, you define these concepts and their relationships in MDriven Designer. You can then add behavior and create user-facing representations of the model.

MDriven follows the model-first principle: the model is the core definition from which artifacts such as generated code and database schema can be derived. Handwritten code can remain alongside generated domain code through partial classes when you use MDriven Framework.

Choose the MDriven part that fits your work

MDriven consists of products with different roles. Use the product that matches how you want to develop and run the application.

Component	What you use it for	Example
MDriven Designer	Create and evolve models, including classes, associations, rules, state machines, and ViewModels.	Model Order, associate it with Customer, and define a ViewModel for an order-entry screen.
MDriven Turnkey	Build a model-driven application front end using the capabilities of Designer and Server.	Present the order-entry ViewModel as a web user interface.
MDriven Server	Run models on a back-end server, manage data, synchronize clients, and execute periodic declarative jobs defined in the model.	Deploy the order model so users work against shared order data.
MDriven Framework	Work with MDriven in Visual Studio, generate the business-layer code corresponding to the model, and access the model from C#.	Add a business-specific C# implementation while retaining the generated domain layer.

Read MDriven Product Line when you need product-level deployment and architecture guidance. Read How does MDriven work for a short operational overview.

Build an application with a model-first loop

Use this loop throughout development. It keeps the model, generated artifacts, and database evolution aligned.

1. Model the domain. In MDriven Designer, create classes for the concepts the application must handle. Add typed attributes and associations. Use inheritance when several classes share a common concept.
2. Capture rules close to the model. Use OCL (Object Constraint Language) expressions for queries, calculated values, and declarative business rules. For example, an order rule can prevent a state change when the order has no order lines.
3. Model lifecycle where state matters. Use a UML state machine when an object's allowed transitions are important. For example, an Order can move from a draft state to a submitted state only through the transitions you define.
4. Create a ViewModel for each user task. A ViewModel is a model representation shaped for a particular screen or interaction. Keep it separate from the domain model so an order-entry task can show the customer, editable order lines, and calculated totals without changing the Order class itself.
5. Execute and inspect the model. Use the modeling and simulation capabilities appropriate to your solution to verify that associations, rules, and lifecycle behavior work as intended.
6. Generate or update derived artifacts. The model can drive generated business-layer code and relational database schema. When the model changes, evolve the database from its existing form toward the form described by the model.
7. Add handwritten code only where it belongs. If a requirement needs C# in a Framework-based solution, keep the model as the primary definition and implement the specialized addition in the supported generated-code extension approach.
8. Deploy the selected runtime. Use MDriven Server when the model is to run on a server, or use the applicable Turnkey or Framework application architecture.

Model the domain before designing screens

A domain model describes the business concepts and their relationships, not the layout of a screen.

For the order example, model the relationship deliberately:

• A Customer can have multiple Order objects.
• An Order has multiple OrderLine objects.
• Each OrderLine belongs to one order.

This structure is useful beyond a single screen. The same model can support order entry, customer history, reporting, and server-side jobs. MDriven uses the model to derive relational persistence structure; database evolution is designed to update an existing database toward the structure described by the model using nonintrusive methods where possible.

For modeling details, including associations, enumerations, constraints, derivation, and persistence, use MDriven Designer.

Put behavior in the right place

Use the following division of responsibilities to keep a model understandable as it evolves.

Need	Put it in	Example
A fact the application stores	Domain class attribute or association	Order.OrderDate or the association from Order to OrderLine.
A calculated value or declarative rule	OCL expression in the model	A value derived from the order's lines, or a rule that checks whether a transition is allowed.
An allowed lifecycle transition	UML state machine	Define the transition from draft to submitted rather than treating status as unrestricted text.
Data and actions needed for one user task	ViewModel	An order-entry ViewModel that exposes an order, its lines, and an action for the task.
A specialized implementation requirement in a Framework solution	C# extension alongside generated code	Implement business-specific behavior while preserving generated domain code through partial classes.

Do not use a ViewModel as a substitute for the domain model. A ViewModel shapes the model for a use case; the domain model remains the definition of the application's information and core behavior.

Use ViewModels and AutoForms to create an initial user experience

A ViewModel defines how data is selected, shaped, and interacted with for a particular use case. MDriven uses OCL expressions with ViewModels to retrieve and manipulate data. AutoForms can generate forms from the model and ViewModels, giving you a starting user interface that you can refine.

For example, create an order-entry ViewModel that provides:

• The selected customer.
• The current order and its order lines.
• Values calculated from the order lines.
• Actions appropriate to the order-entry task.

This is different from exposing every Order attribute in every screen. Create separate ViewModels when the tasks differ, such as one for entering an order and another for reviewing a customer's order history.

See MDriven Designer for ViewModel editing and actions, and How does MDriven work for the relationship between ViewModels, OCL, and AutoForms.

Work with persistence and change

MDriven uses relational databases for information storage. The model can be transformed into relational database schemas, and the built-in evolve function changes an existing database from its original form toward the form described by the model.

Treat a model change as an application change, not only as a database change. For example, when you add a required business concept to Order:

1. Add the attribute and its intended constraints to the model.
2. Review OCL expressions, state transitions, and ViewModels that use Order.
3. Update the database through the model-driven evolution process.
4. Verify existing data and test the updated user task.

MDriven Server documentation describes server-managed SQLCompact, SQL Server, and MySQL databases. The model-driven architecture material also describes transformations to relational schemas for SQL Server, Oracle, MySQL, and other targets. Confirm the supported persistence target for the MDriven product and version you plan to deploy before selecting it.

Extend a Framework-based solution with C#

Use MDriven Framework when you need MDriven Designer embedded in Visual Studio and generated business-layer code corresponding to the model. You have access to the model in C# and can combine OCL and C# for business-specific rules.

Keep the model-first workflow when you add code:

1. Make structural and declarative business changes in the model.
2. Generate or synchronize the corresponding domain layer.
3. Place handwritten extensions in partial classes rather than editing generated code.
4. Use Visual Studio refactoring and MDriven's synchronization capabilities when model changes affect code.

For example, model the Order structure and ordinary rules declaratively. If a business-specific integration requires a C# implementation, add it as an extension rather than duplicating the order model in handwritten code.

Validate before you deploy

Check the model and its use cases at each iteration.

• Test associations with realistic object combinations. For example, verify that a customer can have several orders and that each order line belongs to the intended order.
• Test each OCL rule with both valid and invalid data.
• Test state-machine transitions, including transitions that must be rejected.
• Test each ViewModel as a user task, not only as a data display.
• When persistence evolves, test with existing data as well as a new database.
• Use the Designer testing and simulation material when preparing automated checks, including Selenium testing and simulated logins.

Get started

1. Read Getting Started with MDriven to prepare your environment and learn the core terms.
2. Create a small model in MDriven Designer, such as the customer-and-order example in this guide.
3. Add one declarative rule and one state transition.
4. Create a ViewModel for one user task and use AutoForms to inspect the initial form.
5. Choose Turnkey, Server, or Framework based on how you will run and extend the application.
6. Continue with MDriven Designer for detailed modeling, persistence, testing, integration, security, and refactoring topics.

See also

• Getting Started with MDriven
• How does MDriven work
• MDriven Designer
• MDriven Framework
• MDriven Product Line