You can use MDriven to model, run, and evolve business applications when you want business rules, data structure, and application behavior to remain visible and connected for developers, analysts, and domain experts.

Choose MDriven when the model should be the shared definition

MDriven is a model-driven development platform. Instead of treating diagrams as documentation that becomes outdated, you define the domain model and use it as an executable part of the application.

For example, a team building an order-management system can model Order, OrderLine, and Customer and their relationships. The same model can then drive persistence, generated user-interface starting points, and business behavior. When the business changes the rule for which customer data an order requires, the team changes the model and associated rules rather than maintaining separate, disconnected descriptions.

This approach is a good fit when you need to:

• make the business domain explicit through classes, attributes, relationships, and behavior;
• keep business rules close to the concepts they govern;
• give developers, business analysts, and system architects a common artifact to review;
• create an initial working application from a model and refine it iteratively; or
• change a system over time without treating its original design as disposable documentation.

What you work with

Component	What you use it for	Example
MDriven Designer	Visual modeling of classes, relationships, state machines, and rules.	Model that an Order has many OrderLines and that each line refers to a product.
OCL	Object Constraint Language (OCL) expressions define declarative business rules and UI behavior.	Define when an action is available or when a value is valid from the state of an object.
ViewModel	A ViewModel presents model data and actions to a user interface. MDriven can create interactive ViewModels through Autoforms, which you can customize.	Present an order list, an order-detail view, and the action used to confirm an order.
MDriven Framework	Framework documentation and development options for applications that need code-level extension and integration work.	Add custom behavior where the model and declarative rules are not the right implementation point.
MDriven Server	Runtime and deployment platform for hosting applications built with the MDriven Framework.	Deploy a modeled application for web access while connecting it to its database and external systems.

Why the approach changes everyday development

Put the business domain before implementation detail

In MDriven Designer, you can describe the concepts that matter to the organization before choosing implementation details. A class diagram can show that a customer places orders and that an order contains order lines. A state machine can describe an entity lifecycle and the transitions between states.

The model is not only a drawing. MDriven uses it as an executable definition. This makes the model a practical place to discuss a change with stakeholders: review the class, relationship, rule, or state transition that represents the requirement.

Keep rules where people can find them

OCL is used to express business logic declaratively in the model. This helps a team review behavior in the context of the concepts it affects.

For example, when an order may only be confirmed after it contains at least one order line, model the condition with the order behavior rather than leaving the rule as an undocumented convention in application code. The exact expression and placement depend on the model, but the goal is consistent: the rule is visible alongside the order concept.

See Documentation:Learn OCL for the OCL language and examples.

Start with generated application behavior, then refine it

MDriven can generate database schema and create user-interface starting points from the model. Autoforms can generate interactive ViewModels from the classes you define. You can then adjust user-interface behavior using declarative expressions and customize rendering when the default presentation does not meet the requirement.

A practical iteration can look like this:

1. Model the main concepts and their associations in MDriven Designer.
2. Add the business rules that define valid behavior.
3. Generate an initial UI for the relevant classes and review it with users.
4. Update the model, rules, or ViewModel based on feedback.
5. Add custom code or templates only where the generated and declarative approach does not cover the need.

This workflow makes early feedback useful because users can review a running representation of the modeled domain, not only a written requirement.

Reduce gaps between business, development, and maintenance

A model can provide a common representation for people with different responsibilities. Domain experts can validate whether the concepts and relationships match the business. Developers can use the same model to implement and extend the system. Future maintainers can inspect the model and its rules to understand the intended structure.

For example, rather than explaining a customer-status workflow only in meetings, represent its states and transitions in a state machine. The team can review the workflow directly and update it when the process changes.

Adapt applications as requirements change

Business applications change: a new relationship is needed, a workflow gains a state, or a rule changes. MDriven is designed around evolving the model and regenerating the affected application behavior.

For example, if an order must later support delivery addresses separate from the customer address, add a delivery-address concept and its relationship to the order in the model. Then review the resulting persistence and ViewModels, and adapt the UI and rules where necessary. The model remains the place to understand the change rather than relying on a collection of unrelated code changes.

This does not remove the need for design review, testing, or deliberate migration planning. It gives the team a structured representation from which to make those changes.

Integrate and extend where needed

MDriven does not require every part of a solution to be modeled from scratch. The platform supports integration with external services through REST API integrations and supports custom business logic where needed. The MDriven Framework documentation also covers extending Turnkey with CodeDress and custom persistence mappers.

For example, an application can keep its customer domain model in MDriven while obtaining data from an existing external business system through an integration. Decide which system owns each piece of data, how data is synchronized, and where the business rule belongs before implementing the connection.

See Documentation:Framework for framework development and extension topics.

Run and deploy the application

MDriven Server executes and hosts applications built with the MDriven Framework. The documented deployment options include on-premises and cloud environments, as well as Docker-based container deployment. MDriven Server works with multiple database systems, including SQL Server, PostgreSQL, Oracle, and MySQL.

A typical path is:

1. Create the UML model in MDriven Designer.
2. Define classes, relationships, business rules, and UI behavior.
3. Prepare the database and application behavior from the model.
4. Deploy the application to MDriven Server.
5. Validate the deployed application, its database behavior, integrations, and access requirements in the target environment.

Deployment choices and operational requirements are application-specific. Review Documentation:What is MDriven Server? before selecting the runtime environment.

Decide whether MDriven fits your project

MDriven is especially relevant if your project has a meaningful domain model, changing business rules, and a need for shared understanding across technical and non-technical roles.

If your team needs to...	Evaluate MDriven by...
Clarify a complex domain	Modeling a small but real workflow, such as customer, order, and order-line handling, and reviewing it with domain experts.
Validate rules early	Adding representative OCL rules and testing the resulting behavior against business examples.
Get feedback on application flow	Creating Autoforms and ViewModels for a limited workflow, then having intended users review the running result.
Preserve understanding as the system changes	Recording the concepts, relationships, state transitions, and rationale in the model and reviewing changes there.
Connect to existing systems	Prototyping one bounded integration and agreeing on ownership, data flow, failure handling, and the required extension point.

Start with a focused proof of concept

Do not begin by modeling every part of the organization. Choose one workflow with clear users, data, and rules.

For example, use a small order workflow:

1. Identify the core concepts: Customer, Order, OrderLine, and Product.
2. Model attributes and associations in MDriven Designer.
3. Add one lifecycle rule, such as the condition that permits order confirmation.
4. Generate and review an initial ViewModel-based UI.
5. Ask a domain expert to walk through two examples: an order that can be confirmed and an order that cannot.
6. Make the agreed changes in the model and repeat the review.

This exercise shows whether the team can use the model as a shared definition and whether the generated application behavior provides a suitable starting point for the project.

Continue learning

Begin with Documentation:GettingStarted for installation, setup, and core concepts. Read Documentation:Introduction to MDriven Designer to learn the modeling environment, and use Documentation:MDriven Developer's Guide: Model-Driven Development Simplified for a development-oriented overview.

See also

• Documentation:GettingStarted
• Documentation:Introduction to MDriven Designer
• Documentation:MDriven features and benefits
• Documentation:MDriven Developer's Guide: Model-Driven Development Simplified
• Documentation:What is MDriven Server?
• Documentation:Framework

Start with a small model

Model-driven development means designing a model that defines an application’s data, business logic, and user interface. In MDriven, that model is the backbone of the application, and models can serve as executable definitions.

Start with one focused business process rather than a complete system.

1. Use MDriven Designer to define the process’s business concepts as classes.
2. Add attributes, relationships, and behaviors to describe the relevant data and how the concepts relate to one another.
3. Add business logic with OCL (Object Constraint Language) and declarative rules.
4. Define how model data and actions are presented through ViewModels. AutoForms can generate forms from the model’s data structure and ViewModels.
5. Execute and review the model, then update it as the business process changes.

This approach keeps the model as the central definition of the application’s data, logic, and user interface while allowing the model to evolve with changing business needs.

See also

• How does MDriven work
• Introduction to MDriven Designer

Reliability, deployment, and operational considerations

MDriven describes its platform as scalable and reliable as demand grows. For production deployment, MDriven Server documents capabilities that may support operational management, including automated deployment, load balancing, authentication and authorization, monitoring, and logging.

MDriven Server supports both on-premises and cloud deployments; its FAQ gives Azure and AWS as cloud examples. It is also described as supporting multi-tenant applications. MDriven states that Ecospace synchronization keeps Ecospaces synchronized across multiple servers and clients, and that model updates can result in automatically calculated and applied database-schema changes.

Area	Documented capability
Deployment	Cloud and on-premises deployment support
Operations	Automated deployment, monitoring, and logging
Traffic handling	Load balancing
Coordination	Ecospace synchronization across multiple servers and clients
Security features	Authentication and authorization; RBAC and encrypted communication are listed in the MDriven Server FAQ

These capabilities do not by themselves define a service-level commitment or a complete continuity design. The supplied sources do not provide published uptime targets, recovery-time objectives, recovery-point objectives, incident history, backup procedures, or reliability case studies.

Before approving a business-critical deployment, confirm:

1. The selected cloud or on-premises architecture and who operates it.
2. The load-balancing, backup, recovery, monitoring, and incident-response arrangements for that deployment.
3. Any applicable support terms or service-level agreement.
4. The access-control design for users and administrative roles.

See also

• Documentation:Why You Should Choose MDriven
• MDriven Server

Compare MDriven with other application-development approaches

You can evaluate MDriven against another platform by checking whether it keeps your business logic, data structure, user interface, and deployment workflow connected through one executable model.

MDriven is a model-driven development platform for teams building and evolving business applications. In MDriven Designer, you define classes, relationships, business rules, and workflows visually. The model can be executed and used to generate application parts such as user interfaces and database structures.

Use the same evaluation scenario

Compare platforms with a representative change from your own domain. For example, add an ApprovalRequired rule to an Order, show it in the user interface, persist it in the database, and make it available to an integration. This exposes whether the platform keeps the change aligned across the application or requires separate work in multiple layers.

Evaluation area	What to verify in MDriven	Questions to ask when comparing another platform
Business model	MDriven uses UML models as the primary blueprint for an executable application. The model captures data, relationships, and business logic.	Can you represent the domain structure and rules in a shared model, rather than only in screens or custom code?
Business rules	You can place declarative business logic in the model with OCL.	Can domain rules be expressed and maintained with the model? How are rules reused and enforced when the application changes?
Application generation	MDriven can generate user interfaces, database structures, and application behavior from the model. Autoforms create interactive ViewModels from defined classes.	Which application layers are generated or synchronized from the central definition? What must be built and maintained separately?
Change and iteration	When business needs change, you update the model and regenerate the system. The same model remains the documentation of the business structure.	For the Order approval example, how many artifacts must be changed? Does the implementation remain understandable after several iterations?
Integration and modernization	MDriven can work alongside existing systems, integrate through APIs, expose ViewModels as REST endpoints, and extend logic with custom C#.	Can the platform add capabilities around an existing CRM, ERP, or legacy database without requiring a replacement project?
Deployment options	MDriven supports deployment in cloud, on-premise, or Docker environments.	Which deployment environments are supported, and what changes are required to move between them?
Team collaboration	Visual models let domain experts review the same business structure used by the application, reducing dependence on knowledge held only in individual developers.	Can business experts review the real rules and structure? Does the platform provide a reusable description of the system rather than relying on tribal knowledge?

Identify the MDriven fit

MDriven is a strong fit when your application has a long-lived business domain that must remain understandable while rules, workflows, and technology evolve. For example, a team modernizing an internal order process can model Orders, approval states, and validation rules; generate the supporting application; and retain the model as the shared description of how the process works.

Use the comparison to test the concerns that matter to your project: preserving business knowledge when team members change, integrating with existing systems, avoiding a rip-and-replace migration, and evolving the application without separating the model from the implemented system.

See also

• Documentation:Why You Should Choose MDriven
• Documentation:MDriven features and benefits
• Documentation:Introduction to MDriven Designer
• Training:What is MDriven

Find documentation by task

Use these categories to choose the next MDriven topic for your work.

If you want to...	Start here
Learn the MDriven Designer and organize a model	MDriven Designer overview Part 1
Write expressions and constraints in Object Constraint Language (OCL)	OCL documentation
Show, search, filter, and order data in tables	Tables, search and ordering
Style the user interface	MDriven Stylesheet
Configure, develop, deploy, or troubleshoot an application	HowTos

For example, start with OCL documentation when you need to write an expression, or open HowTos when you need a step-by-step configuration or deployment guide.