Use this page to compare MDriven with another low-code platform when you need to evaluate how each product represents, executes, extends, and deploys a business application.
Compare the development approach
MDriven is a model-driven development platform: you define the domain model, business rules, and user interface behavior in a model, then use that model as the basis for the application. MDriven Designer is used to create the model, and MDriven Server runs and hosts deployed applications.
For example, model an Order class associated with an OrderLine class, define validation for the order, and create a ViewModel for an order-entry screen. The same model can drive the data structure, application behavior, and generated user interface.
| Evaluation area | What to establish for MDriven | What to ask of each alternative |
|---|---|---|
| Primary application definition | MDriven uses UML-like domain models as the single source of truth for business entities, relationships, and rules. | What artifact is the source of truth: a domain model, application screens, source code, configuration, or several separate artifacts? |
| Business rules | You can define validation and business logic with OCL (Object Constraint Language) expressions and model object lifecycles with state machines. | Can you define validation, calculations, and lifecycle rules declaratively? Where are those rules stored and maintained? |
| User-interface shaping | A ViewModel shapes domain data for a specific use case without changing the domain model. AutoForms can generate forms from the model and ViewModels, and you can customize UI behavior with OCL expressions or templates. | Can you create a task-specific view without changing the core data model? How are generated forms customized? |
| Persistence and schema evolution | MDriven persists application data from the model and supports model changes that evolve the schema. | Which databases are supported? How are schema changes applied when the application model changes? |
| Integration and extension | MDriven can integrate external services through REST APIs and can be extended with custom code. | How are REST integrations implemented? Which programming languages, libraries, and extension points are available when declarative configuration is not enough? |
| Deployment | MDriven applications can be deployed through MDriven Server on-premises or in cloud environments, including Docker-based deployments. | Which hosting environments are supported? Can you deploy on-premises, in your chosen cloud, or in containers? |
| Security and workflow | MDriven supports role-based access control in the model. | Where are access rules defined, and how are workflow states and transitions represented? |
Run the same evaluation scenario
Use one small but representative business scenario in every product evaluation. For example, evaluate an order-management application with customers, orders, order lines, approval states, and role-based access.
- Define the customer, order, and order-line data structures and their relationships.
- Add a rule that validates an order before approval.
- Model order states such as Draft, Submitted, and Approved.
- Create an order-entry view that shows order lines and a computed total.
- Expose or consume one REST-based integration.
- Change the model by adding an approval-related attribute, then observe the impact on the database, UI, rules, and deployment process.
In MDriven, this scenario tests the connection between the domain model, OCL rules, state machines, ViewModels, generated forms, persistence, and MDriven Server deployment.
Questions for the evaluation team
- Can domain experts read and discuss the application definition with developers?
- Does one change require updates in multiple layers, such as the database, API, and UI, or can the model drive those updates?
- Can developers add C# code where the model does not cover a requirement?
- Can the application connect to existing systems through REST APIs?
- Does the deployment option meet the organizationâs cloud, on-premises, or container requirements?
- Can the team maintain business rules and workflow definitions after the original project members leave?