This page helps MDriven architects decide when a service-oriented architecture (SOA) is appropriate and how to split a model only when a measured load problem requires it.
What SOA means in an MDriven solution
Service-oriented architecture (SOA) is an architecture in which separate system parts cooperate through service interfaces rather than running as one application. A microservice is a smaller service unit with its own persistence; in this context, each microservice remains a monolith internally and communicates with other units over the network.
In MDriven, a service split means drawing a boundary through the model. Each side of the boundary becomes an independently deployed, model-driven application part with its own database or persistence ownership.
For example, if a model has about 100 closely related classes for order processing and another 100 closely related classes for reporting data, and each area creates significant database load, the two areas may be candidates for separate services. The boundary must follow weak model dependencies, not an organizational preference for separate codebases.
Start with a monolith
Start with one application and one database when you do not have a specific scaling or load bottleneck. This keeps communication in-process, uses a single build and deployment unit, and is resource-efficient at small scale.
MDriven supports rapid development without requiring you to divide the application into services early. Model the information and business behavior first. The content of the applicationâsuch as what an invoice is and how invoices must be handledâis the primary architecture concern. Infrastructure choices, such as caches or cloud components, support that content but do not define its business value.
A MDriven Turnkey application also has defined physical tiers: the browser client, Turnkey web application, MDriven Server, and database. These tiers are responsibilities within an application architecture; they do not by themselves mean that the application is split into independent services.
Split only for a concrete problem
Split a monolith when you have identified a problem that a split solves, typically database load or a performance bottleneck. Do not split components only to make the architecture look scalable or to give teams isolated areas of code.
Use these checks before introducing a service boundary:
- Identify the bottleneck. For example, establish that order-processing queries overload the same database that serves reporting.
- Inspect associations and dependencies in MDriven Designer. Look for two model areas with weak dependencies between their classes.
- Confirm that both sides have enough data and load to benefit. Splitting a small or lightly used area adds cost without reducing a meaningful load.
- Define which service owns each piece of data and which service may write it.
- Define the contract and synchronization needed for references that cross the boundary.
Handle cross-service references
A model split does not remove all associations between the two areas. References that formerly navigated in one model can become cross-service reference-data problems.
Keep a local copy of reference data when a service needs to read it locally. Assign one service as the writer and make the other service read-only for that copy. Exchange messages between the services to keep the copy synchronized.
For example, the Order service can own and write Customer records. A Reporting service can retain a local, read-only copy of the customer name and customer number needed for reports. When a customer changes, the Order service sends the changed reference data to the Reporting service. The Reporting service must not write the copied customer record.
This arrangement introduces data copies and synchronization delay. Design the service contract around that fact; do not assume that a cross-service association behaves like an in-process association.
Account for operational cost
A service split replaces in-process calls with network communication and adds deployment and monitoring work. It also increases the number of cooperating units and the overall boxes-and-lines complexity.
| Area | Single application | Split services |
|---|---|---|
| Communication | In-process between application parts | Network communication between service parts |
| Deployment | Usually one build and deployment unit | Deploy one or more services; coordinate contract changes |
| Persistence | One database can serve the application | Each service owns its persistence |
| Cross-area data | Direct model associations | Contracts, messages, and synchronized local copies where needed |
| Primary reason to choose it | Fast learning and a simple initial architecture | Resolve a demonstrated load or performance problem |
When deploying, decide whether one service or both services must be deployed. If you changed the contract between them, deploy the compatible changes together or maintain compatibility during the transition.
Service interfaces from MDriven
MDriven can consume REST services and expose REST services from a running system. For SOAP integrations, use the selfVM.SoapCall OCL verb from a ViewModel. See Documentation:SOAP the protocol from the stone age for the SOAP call parameters and a ViewModel action example.
For example, a ViewModel action can call an external SOAP method and store its response in a ViewModel variable. That integration is a service interaction; it does not require you to split your own application into microservices.
Avoid architecture-driven migrations
Changing from a monolith to microservices can create long-running migrations. Treat this as a business and technical change: preserve the meaning of the model, define data ownership, and introduce contracts before moving data and traffic.
Do not make a service split a substitute for understanding the model. A clear model with well-understood classes, associations, and ownership is the prerequisite for a safe boundary.