A microservices architecture helps MDriven solution architects split an application into independently deployed services when scale or operational needs require it.
When to use microservices
A microservice is a separately deployed application that owns a focused part of an overall solution. Do not split an application only to adopt a microservices style. Split it when the division addresses a real problem, such as load on a database, a need to scale a specific capability, or an independently managed external boundary.
For example, a solution may separate payment handling from order management when payment processing has distinct scaling or integration requirements. The resulting services communicate through defined interfaces rather than sharing implementation details.
Re-architecting can be a sign that an application has succeeded: usage, data volume, or required scale has exceeded what the original architecture needed to support.
Start with the model
In MDriven, find service boundaries by examining the information model. Draw a potential boundary where groups of classes have weak dependencies and few associations between them.
For example, if roughly 100 classes describing orders have limited dependencies on roughly 100 classes describing payments, the two areas may be candidates for separate services. The split is meaningful when both sides carry enough data or load that separating them reduces the problem each database must handle.
Do not split a model where the two areas are tightly connected. Cross-service references introduce coordination problems, so a boundary with many required associations is a poor candidate.
| Question | What to look for |
|---|---|
| Are dependencies weak? | Few associations and limited navigation between the two model areas. |
| Does each side have sufficient load or data? | Each service handles a meaningful part of the scaling problem. |
| Does the split solve a stated problem? | For example, partitioning persistence to reduce database load or isolating a payment integration. |
| Is the reason only organizational preference? | Keep the application together until a technical or operational need exists. |
Expose and consume service interfaces
Use REST interfaces when services need to exchange requests and responses. A REST service is invoked through a URL that identifies an operation and its parameters, and commonly returns JSON.
MDriven Turnkey can expose a REST API and can call external REST services. This supports a service boundary without requiring the receiving system to use the same implementation technology.
To expose a ViewModel as a REST endpoint, set the RestAllowed tagged value on the ViewModel that provides the data or operation. For example, set RestAllowed to true on a ViewModel that returns a car catalogue, then deploy it to Turnkey so another service can request that catalogue.
To call another service from a ViewModel, use the REST operators on selfVM in Rest Services In MDriven. The available operators include:
selfVM.RestGet(...)to retrieve a response.selfVM.RestPost(...)to send data to a service.selfVM.RestDownload(...)to retrieve a downloaded file.
For example, an order ViewModel can use selfVM.RestPost(...) to submit payment data to a payment service. Put authentication headers, such as a bearer token, in the named nesting supplied to the operation. Define the action logic with OCL and the relevant EAL operators in the ViewModel context.
Plan persistence and communication
As services become separate applications, partition persistence by function. Avoid treating one monolithic database as the permanent shared implementation boundary. A service responsible for one group of entities should have persistence designed for that group.
For example, an order service can own order and order-line data, while a payment service owns payment transaction data. If a service needs information from another service, obtain it through the service interface or an agreed message flow rather than directly relying on the other service's internal data structure.
At larger scale, services may communicate through an event queue or message broker. This is useful when applications need to exchange messages without each request waiting for the receiving service to complete its work.
Control maintenance cost
Microservices add operational responsibilities: more deployments, interfaces, persistence boundaries, and diagnostics. The maintenance cost after initial development is often larger than the initial implementation cost.
Avoid extracting a service by copying existing business logic and recreating it elsewhere unless the expected operational benefit is clear. Existing code may contain business changes and unresolved defects that are difficult to identify and reproduce. Maintain business content in the MDriven model where possible, so you can understand and evolve the model instead of reverse-engineering behavior from code.
Use detailed logging and instrumentation while you iterate. Record which views and actions users use, how often they use them, and how they perform. This data helps you identify whether a proposed split addresses an observed bottleneck.