You use MDriven architecture to define a business system in a model and let that model drive its user interface, runtime behavior, generated code, and relational persistence.

Architecture at a glance

MDriven keeps business concepts in a model and separates them from the technical services that execute and store them. You model the domain once, then use the same definitions to create and run an application.

For example, a sales solution can define Customer, Order, and OrderLine in the model. An Order can have many OrderLine objects, and an OrderLine belongs to one Order. From this definition, MDriven can provide business-object behavior, a user interface based on a ViewModel, and relational storage for the objects.

Area	Responsibility	Example
Model	Defines the domain, rules, processes, documentation, ViewModels, views, and actions.	An Order has a date, a customer, and order lines.
Generated and handwritten code	Implements the application around the model. Generated artifacts retain the model definition; handwritten code can provide selected custom implementations.	A developer implements a selected derived value in code while the remaining model structure is generated.
Runtime	Tracks objects, relationships, changes, transactions, undo/redo, and data access while the application runs.	Adding an order line updates the in-memory order relationship within the current transaction.
Persistence	Maps model objects to a relational database and evolves the database when the model changes.	The Order and OrderLine classes are stored in relational tables.

Start with the model

The model is the primary description of the system. You create it in MDriven Designer using Unified Modeling Language (UML). It can contain:

• Classes, attributes, and inheritance to describe business concepts. For example, Customer can be a class with a Name attribute.
• Associations to describe relationships. For example, Order has many OrderLine objects. A many-to-many relationship can use an association class when the relationship itself needs information.
• Derived attributes and constraints expressed with Object Constraint Language (OCL). A derived Total value can be calculated from the order lines rather than stored independently.
• ViewModels that select and organize model data for a task or screen. A ViewModel can expose an order together with its customer and lines for order entry.
• ViewModel Views that declaratively describe the user interface for a ViewModel.
• Actions defined with Extended Action Language (EAL) to express operations available to the user. For example, an action can submit an order after its required information is present.
• State machines, constraints, and process information to capture lifecycle rules and the context of the solution.
• Documentation attached to model artifacts, such as the meaning of an attribute or the reason for a rule.

The model is also a shared place to capture terminology and background knowledge. Use documentation on a class such as Order to state what the business means by an order, rather than leaving that meaning only in external notes.

Build a working model in steps

1. Create the domain classes and associations in MDriven Designer.
2. Add attributes and rules. For example, define the values needed for an order and use OCL for values derived from related objects.
3. Create a ViewModel for a user task, such as entering or reviewing an order.
4. Define the ViewModel View and actions for that task.
5. Run the model to inspect the objects and the generated user interface.
6. Update the model as requirements change, then apply the corresponding persistence evolution when the database schema must change.

This workflow lets you test the business structure and user task before adding selected handwritten extensions.

Prototype before deployment

Use the prototyping capabilities to execute the model early. You can create objects and inspect automatically generated forms for classes, which is useful when validating the domain structure with stakeholders.

For example, create a Customer, then create an Order associated with that customer. Inspect the resulting form and confirm that the information and relationships match the intended workflow. When the task needs a focused screen rather than a class-oriented form, define a ViewModel and its ViewModel View.

The runtime executes the model

At runtime, MDriven manages the business objects loaded from persistence and the relationships between them. This removes the need for application code to manually maintain every relationship update or track which objects are currently loaded.

The runtime provides these services:

• In-memory transactions. Changes belong to a transaction context. If processing fails, the transaction can be rolled back.
• Undo and redo. Unsaved changes can be tracked in an undo/redo queue.
• Object and association management. When you connect objects, the runtime manages the relationship state.
• Query execution. LINQ or OCL can be used to execute database queries.
• Optional domain services. The framework includes capabilities such as undo/redo, versioning of selected classes, and declarative action definitions. See Documentation:MDriven Framework – a Model driven framework.

For example, while editing an order, a user can add lines and change quantities. Those changes remain part of the current transaction until the application saves them. If a rule or action fails, the application can roll back the transaction rather than leaving a partial order update.

Generated code and handwritten extensions

The model is represented in generated artifacts as attributes. You can add handwritten code alongside generated code, including implementations for selected derived attributes or associations. MDriven separates handwritten code from generated code through incomplete classes, so the handwritten part is not replaced when the model is regenerated.

Use this separation deliberately:

• Keep domain structure, declarative rules, ViewModels, views, and actions in the model when they can be expressed there.
• Add handwritten code for a selected implementation that the model does not express.
• Do not edit generated output as the place for durable custom logic; place durable custom logic in the handwritten part.

Persist the model in a relational database

Object-relational mapping (OR mapping) maps the UML model to a relational database. The PersistenceMapper retrieves business objects from the database and stores changes back to it.

The mapping includes choices such as how to map inheritance. You can accept the standard mapping or customize it when the application must work with an existing database. MDriven also supports reverse derivation from an existing database at design time.

When the model changes, DB-Script evolution calculates the database changes needed for the existing schema. For example, after adding a RequestedDeliveryDate attribute to Order, use DB-Script evolution to identify the database change required for that new value.

Deploy with Turnkey

MDriven Turnkey is a deployment approach that uses ViewModels as the boundary between the client user interface and the application logic. The client displays and updates ViewModel properties; actions and business logic execute on the application side.

In the Turnkey architecture, the MDrivenServer handles object persistence and client synchronization, while the database provides storage and SQL search. The application layer maintains per-user ViewModel state, transactions, and unsaved-change undo/redo behavior. Refer to the MDriven Turnkey Series for the deployment architecture and configuration guidance.

For example, when a user changes an order quantity in a Turnkey client, the update is sent as a ViewModel change. The application layer applies the associated logic and transaction handling, retrieves required business objects through MDrivenServer, and returns the ViewModel changes needed to refresh the client.

Choose the right level of detail

Use this page to understand the architectural responsibilities. Use the following pages when you need implementation guidance:

• Learn the platform concepts in Training:What is MDriven.
• Review the framework and its runtime and persistence capabilities in Documentation:MDriven Framework – a Model driven framework.
• Follow the product workflow in Documentation:MDriven Developer's Guide: Model-Driven Development Simplified.
• Learn Turnkey deployment through Documentation:MDriven Turnkey Series.

See also

• Training:What is MDriven
• Documentation:MDriven Framework – a Model driven framework
• Documentation:MDriven Developer's Guide: Model-Driven Development Simplified
• Documentation:MDriven Turnkey Series
• Capable Objects

Architecture for evaluators

MDriven's documented architecture centers on a model expressed in Unified Modeling Language (UML). The model can define class diagrams, inheritance, many-to-many associations with association classes, derived attributes using Object Constraint Language (OCL), ViewModels, declarative user interfaces, actions, state machines, constraints, and information about processes, stakeholders, applications, and terminology.

For example, an order-management model could define Customer, Order, and OrderLine classes and the associations between them. This example illustrates the modeling concepts; it is not a prescribed MDriven schema.

Terms used in the documented architecture

Term	Documented role
UML	The model is expressed in Unified Modeling Language (UML). It can define classes, inheritance, associations, state machines, and other model information.
OCL	Object Constraint Language (OCL) is used for derived attributes and for folding pieces of the model into ViewModels. The ECO runtime can also use LINQ or OCL to execute SQL queries against the database.
EAL	Extended Action Language defines actions. In WECPOF, Action definitions can render menus.
ViewModel	A ViewModel is a model construct. The architecture documentation states that pieces of the model can be folded into ViewModels with OCL.
ViewModel View	A ViewModel View is used to design declarative user interfaces for a ViewModel.
WECPOF	WECPOF can render user interfaces from declarative ViewModels and render menus from Action definitions, producing an application that can be tested with users.
ECO runtime	At runtime, ECO manages loaded data and associations. The documentation also lists in-memory transactions, undo/redo, and LINQ or OCL database queries among its services.
ECO PersistenceMapper	ECO PersistenceMapper is identified as an architecture component in the documentation. The supplied passage does not describe its mapping behavior or configuration options.

From model to application

The documented flow begins with the UML model. MDriven can transform a platform-independent model (PIM) into C# code, relational database schemas, and ViewModel-based user controls for WPF, ASP.NET, and Angular. The documentation describes MDriven as geared toward the .NET arena.

In the Visual Studio architecture, generated code contains model information as attributes on generated artifacts. Handwritten code can also be included; the documentation says incomplete classes separate handwritten code from generated code. MDriven's model-driven-development guidance states that changes are made in the model first and then propagated to derived artifacts, while handwritten additions to the generated domain layer are retained through partial classes.

Runtime behavior

When an application loads data from a database, the ECO runtime manages what is loaded and the associations between objects. The documentation describes in-memory transactions: application code can throw an exception and roll back the transaction. It also lists a complete undo/redo stack and the ability to use LINQ or OCL to execute SQL queries.

Database-related statements supported by the supplied sources

The model-driven guidance states that MDriven can transform a PIM into relational database schemas, including schemas for SQL Server, Oracle, and MySQL. It also states that a built-in evolve function updates an existing database after model changes using nonintrusive methods as much as possible.

The supplied architecture passage names ECO PersistenceMapper but does not provide sufficient detail to describe its object-relational mapping strategy, database reverse engineering, inheritance mapping, customization options, or precise migration behavior.

Evaluation matrix

Area	MDriven statements supported by the supplied sources	OutSystems	Mendix	Power Apps
Model definition	UML models can define classes, inheritance, associations, derived attributes, ViewModels, declarative UI definitions, actions, state machines, constraints, and documentation-related information.	Not documented in the supplied sources.	Not documented in the supplied sources.	Not documented in the supplied sources.
Expressions and actions	OCL is used for derived attributes and ViewModels; EAL defines actions. The runtime can use LINQ or OCL for SQL queries.	Not documented in the supplied sources.	Not documented in the supplied sources.	Not documented in the supplied sources.
UI generation	ViewModels can be transformed into user controls for WPF, ASP.NET, and Angular. WECPOF can render UIs from declarative ViewModels and menus from Action definitions.	Not documented in the supplied sources.	Not documented in the supplied sources.	Not documented in the supplied sources.
Database-related capabilities	MDriven can transform a PIM into relational database schemas. A built-in evolve function can update an existing database after model changes.	Not documented in the supplied sources.	Not documented in the supplied sources.	Not documented in the supplied sources.
Runtime services	ECO runtime services listed in the documentation include management of loaded data and associations, in-memory transactions, undo/redo, and LINQ or OCL SQL queries.	Not documented in the supplied sources.	Not documented in the supplied sources.	Not documented in the supplied sources.
Documented technology direction	MDriven is described as geared toward the .NET arena; the supplied source explicitly documents transformation to C# code.	Not documented in the supplied sources.	Not documented in the supplied sources.	Not documented in the supplied sources.

Code generation and model alignment

MDriven is model-centric: changes are made in the model first and then applied to derived artifacts. MDriven can generate C# code from the model and can also transform the model into relational database schemas.

In a Visual Studio project, generated model code and handwritten code can coexist. The generated artifacts carry model information as attributes, while incomplete/partial classes separate handwritten additions from generated code. This allows generated code to be refreshed without replacing handwritten additions.

Keep model representations synchronized

Several representations of a model may be involved:

• The model used when running from the designer.
• The model uploaded to MDrivenServer, which is used for PS calls to the server and for the server web UI.
• Compiled code, whose model information is reflected back when the EcoSpace starts at runtime.

When generated code is used, refresh C# generation and build the project before uploading the model. If CodeDress is used, the documentation recommends compiling generated code before upload so that old assemblies containing an older model are not sent to MDrivenServer.

See also

• Documentation:Code generation
• Documentation:MDriven Architecture
• Model-Driven Architecture