- Complexity shows up early—use the tools that expose and manage it
You can build business-led applications that grow in complexity without hiding that complexity from your team; this page is for MDriven modelers who need to inspect and manage the data dependencies of a ViewModel.
- Start with the business problem
Listen to the people who do the work. Their terminology, rules, and exceptions are the domain your application must support.
A small request often develops over time. For example, an innovation team may initially ask you to track:
- which articles belong to a product-development project, and - the development state of each article.
Later, the same team may need packaging components, suppliers, logistics solutions, barcode formats, approval votes, regulatory information, and responsibility information in the same work area. These are not necessarily unnecessary features. They are refinements of the information the team needs to make decisions.
Model these concepts using the language used by the business. This is the Domain-Driven Design (DDD) principle of a shared, or *ubiquitous*, language: developers, modelers, and domain experts use the same terms for the same things. See Model-Driven Architecture for the broader modeling principle.
Do not try to prevent all complexity by refusing valid requirements. Instead, make the complexity visible, keep it understandable, and use MDriven's declarative tools to manage it.
- Why a ViewModel becomes complex
A **ViewModel** is MDriven's declarative description of a use case, including the data shown and the interaction presented to the user. One ViewModel can contain several coordinated levels of information.
Consider a packaging-oriented project view with five main levels:
1. A project. 2. The articles in that project. 3. Packaging components for the selected article. 4. The active logistics solution for the selected article. 5. Barcodes for the selected article.
Each level can look moderate when viewed on its own. A grid may show a few article details; another grid may show the components used by that article. The complexity is in the combined dependency graph: expressions in one ViewModel can navigate through many classes and associations.
For example, if five visible levels each rely on approximately six classes, the ViewModel can reach about 30 classes. The exact count is less important than the consequence: a user interaction that appears to be one screen can require data from a broad part of the domain model.
This is normal in a mature business system. Treat it as something to inspect and manage, not as evidence that the model is wrong.
- Inspect expression dependencies
Use the ViewModel analysis to see which classes and associations its expressions access.
1. Open the relevant ViewModel in **MDriven Designer**. 2. Open the **ViewModel dialog**. 3. Select **Analyze expressions**. 4. Review the generated diagram. 5. Identify the paths that connect the ViewModel's starting objects to the data shown in each level.
The generated diagram gives you a concrete answer to questions such as:
- Which classes does this ViewModel access? - Which associations connect those classes? - Which derived values cause the ViewModel to navigate beyond the classes visible in the UI?
For the packaging example, the diagram may show paths from `Project` through article changes and article revisions, then onward to component usages, component specifications, suppliers, logistics solutions, and related approval information. The UI may contain only two grids, but the expressions supporting those grids can depend on all of those paths.
- What to look for
Focus on dependency paths rather than only the number of classes.
| Inspect | Why it matters | Example | |---|---|---| | Classes reached by expressions | Shows the domain breadth of the use case. | An article grid also reads article revisions, votes, and regulatory domain information. | | Associations on each path | Shows how the data is reached. | `Project` → article change → affected article revision → component usage. | | Derived attributes and derived associations | These can introduce dependencies that are not obvious from the screen layout. | An attribute displayed on an article is derived from related approval votes. | | Repeated paths | Repeated navigation may be relevant when you investigate loading behavior. | Several columns navigate from an article revision to related component data. |
A **derived attribute** is an attribute calculated from an expression rather than stored as an independently entered value. A **derived association** is an association end calculated from an expression. MDriven commonly expresses these calculations in **OCL** (Object Constraint Language), the declarative expression language used in the model.
For a small example, a `Project` can derive the number of tasks with:
```ocl self.tasks->size ```
The expression is concise, but it still establishes a dependency from `Project` to its `tasks`. In a larger ViewModel, many such expressions can form a substantial dependency graph. For an introductory OCL example, see How to Build a Team Task Planner in 15 Minutes with MDriven.
- Understand the performance risk
The dependency graph matters because the application must retrieve the data required by the ViewModel.
In 2018, MDriven identified a case where data look-ahead did not handle derivations efficiently enough. Derived attributes and associations could be skipped during the initial look-ahead. When the UI was drawn, accessing those derivations caused lazy fetching: many individual database queries instead of efficient planned retrieval.
This behavior was most noticeable when users were far from the server.
- Latency makes extra queries visible
- Latency** is the time it takes for a request and response to travel between systems. If an interaction causes many separate database queries, each query adds its own delay.
For example:
| Per-request latency | Effect of many individual queries | |---|---| | 10 ms | The delay may be difficult to notice. | | 100 ms | Repeated queries can make the view feel slow. | | 400 ms | The problem becomes obvious during testing, even when this does not represent your normal deployment. |
The key point is not that a particular latency value is acceptable. The key point is that query count and latency multiply. A ViewModel that performs acceptably near the server can become slow for remote users if it triggers repeated, individual fetches.
- Use Query Plans to manage retrieval complexity
MDrivenServer uses the declarative ViewModel and its OCL expressions to look ahead and retrieve required data efficiently. The response to the derivation-related loading issue described above was a **Query Plan**.
A Query Plan is the generated retrieval plan that describes the object types and association structures MDrivenServer needs to reach for a ViewModel. It lets the server use the ViewModel's declared dependencies rather than relying on the UI to discover them one query at a time.
For the packaging example, a Query Plan can include entries conceptually like these:
- start from `Project` and reach related article changes; - reach the affected article revision and its component usages; - reach each component specification and its packaging supplier; - reach the active logistics solution and its logistics specifications; - reach users and approval votes needed for displayed responsibility and approval data.
The full plan can be long because it represents the real object graph used by the ViewModel. That length is useful diagnostic information. Do not treat a long plan as a list to maintain by hand; use it to understand the scope of the use case and to investigate unexpected retrieval paths.
- A practical workflow for complex views
Use this workflow when a ViewModel has grown over several iterations or when users report slow loading.
1. **Confirm the user need.**
Identify the decision or task the view supports. For example: “The innovation team must review an article's packaging, logistics, and barcode information while working in its project.”
2. **Keep the domain language exact.**
Name classes and associations after business concepts, such as `ArticleRevision`, `ComponentUsage`, or `LogisticSolutionRev`, when those are the domain's terms. Avoid technical abstractions that obscure what the business means.
3. **Inspect the ViewModel.**
Run **Analyze expressions** in the ViewModel dialog. Review the generated diagram before guessing which data the view needs.
4. **Trace derived values.**
For each important displayed value, identify whether it is direct data or a derived attribute or association. For example, a logistics status might depend on an article revision's active logistics solution and related logistics specifications.
5. **Review the Query Plan.**
Check whether the plan includes the structures needed to reach the displayed data. Use it to understand retrieval breadth, especially when derivations are involved.
6. **Test under representative network conditions.**
Test with latency that represents how your users connect to the application. Also use higher simulated latency to reveal repeated-query behavior that low-latency development environments can mask.
7. **Refine based on evidence.**
If the analysis reveals an unexpected path, revisit the relevant OCL expression, derivation, association, or ViewModel design. Do not optimize based only on the number of classes in the diagram.
8. **Repeat as requirements change.**
New requirements can legitimately add classes and paths. Re-run the analysis whenever you extend a complex ViewModel.
- Keep complexity explicit, not accidental
MDriven supports iterative refinement: you define classes and associations, test them with data, refine views for specific use cases, and adjust the model as users give feedback. See Build Enterprise Information Systems for that lifecycle.
This approach does not promise that a business domain will remain small. It gives you artifacts that make growth inspectable:
- UML classes and associations show the information structure. - OCL expressions show derived business logic. - ViewModels show the use cases and UI data requirements. - **Analyze expressions** exposes the dependency graph. - Query Plans expose the retrieval structure MDrivenServer uses for the ViewModel.
A complex view is manageable when you can explain why each dependency exists, verify that it supports a user need, and test how it behaves under the conditions in which users work.
- Related guidance
- Model-Driven Architecture — model with the language and concepts of the domain. - Build Enterprise Information Systems — iterate from classes and associations to views and user feedback. - Discovering Business Requirements — structure discovery with process, class, and state diagrams. - Types of Software Bugs — accommodate changing understanding as the system evolves. - Reality and the Theoretical Best Model — continuously refine the model to follow a changing business reality.