You can use this page to identify the documented boundaries of MDriven modeling; it is for architects and developers evaluating whether a proposed system fits the available documented scope.
Documented boundary
A model represents the parts of reality that matter to the business; it does not replace reality. Define a clear goal before modeling so that you can decide what information, relationships, and rules belong in the model.
Constraints to assess for each solution
MDriven Designer documentation describes modeling, data persistence, SQL database integration, ViewModels, OCL, integrations, and performance work. Evaluate the specific model and deployment design against those areas rather than assuming a limit or capability that is not documented here.
| Area | What to establish for the solution | Example question |
|---|---|---|
| Model scope | Which business concepts and rules are important enough to represent in the model. | Does the order-completion rule belong in the model, or is it outside the system's purpose? |
| Validation | Which data rules must be enforced through data validation and OCL. | Must every order have a customer before it can be saved? |
| Delivery design | Which ViewModel data and interactions the chosen client must present. | Must an order editor show the order lines while the user edits the order? |
| Persistence and operations | The database, hosting, security, performance, and integration requirements for the deployment. | What database, expected workload, and external services must the order application use? |
Limits not currently specified
The current documentation does not specify numeric or support boundaries for database size, concurrent users, OCL recursion depth, tenant isolation, supported integrations, or scaling topology. Do not treat the absence of a published value as confirmation that a configuration is supported.
Record the required workload and architecture for each project and obtain confirmation for requirements that depend on such limits.