What do the CIM, PIM, and PSM layers represent in the Model Driven Architecture (MDA) approach to Model-Driven Design, and how does a change flow between them?

## Why the layers exist The CIM/PIM/PSM split comes from the OMG's Model Driven Architecture (MDA) specification, and it exists to answer a specific problem: **business requirements and implementation technology change at very different rates**, and conflating them in a single model makes both harder to manage. Business rules for how orders are processed might be stable for years; the technology used to implement them — a monolith today, microservices with an event bus tomorrow — can change every couple of years. MDA's answer is to model each concern at its own layer, so a change to one doesn't force a rewrite of the other. ## The three layers | Layer | What it captures | |---|---| | **CIM** — Computation Independent Model | The domain's vocabulary, business processes, and rules, in terms a domain expert can validate | | **PIM** — Platform Independent Model | Structural elements that satisfy the CIM's requirements, neutral about the target technology | | **PSM** — Platform Specific Model | One concrete technology stack, from which MDA envisions final code generation as close to mechanical | The **Computation Independent Model (CIM)** sits at the top and is deliberately software-free: it captures the domain's vocabulary, business processes, and rules in terms a domain expert, not a developer, can validate, with no mention of classes, databases, or APIs. Its job is to pin down what the business needs, independent of how it will be built; think of it as closer to a business process model or a domain glossary than a software design. Below it, the **Platform Independent Model (PIM)** is where software design begins: it introduces structural elements — classes, associations, state machines, operations — that satisfy the CIM's requirements, but stays neutral about the target technology. A PIM might say an `Order` has one or more `OrderLines`, and placing an order that fails inventory validation must roll back, without saying anything about SQL, REST, or a particular language. The **Platform Specific Model (PSM)**, finally, takes that PIM and binds it to one concrete technology stack: the same association might become a PSM described in terms of JPA annotations and a relational schema, or, for a different target, a PSM described in terms of a document-store's single-table design. From the PSM, MDA envisions final code generation as close to mechanical. ## Transformation is what ties them together The mechanism that ties the layers together is **transformation**: MDA's vision, formalized via OMG's Query/View/Transformation (QVT) language, is that each lower layer is produced by an automated or semi-automated transformation from the layer above, so a change to the CIM can be propagated down, and, crucially, the same PIM can be transformed into multiple PSMs to retarget the same business logic onto different platforms without redesigning it. This is the layer separation's main selling point: platform independence as reuse, not just as a modeling nicety. ## The trade-off The trade-off is up-front cost and tooling maturity against long-term reuse and clarity. - Maintaining three synchronized layers plus code means every non-trivial change potentially has to be threaded through CIM, PIM, PSM, and generated code. - The automated-transformation tooling that makes this tractable is heavyweight, has a steep learning curve, and in practice is far less mature and far less automated than the MDA vision promises — many shops end up hand-writing the CIM-to-PIM and PIM-to-PSM transformations as documentation exercises rather than executable transformations, which erodes much of the payoff. - Teams that adopt the full three-layer split for a project with one fixed platform and no realistic prospect of re-platforming are paying maintenance overhead for reuse they will never cash in. ## Failure modes at the seams Failure modes concentrate at the seams. 1. **A common one is CIM/PIM conflation:** the business model quietly accumulates software-design details — a CIM element gains a database reference — because nobody enforces the boundary, at which point the CIM stops being reviewable by non-technical stakeholders, which is its whole reason for existing. 2. **Another is PIM/PSM drift** when platform-specific hand-tuning, like a manually added database index or a denormalization for performance, happens directly in generated code or the PSM without ever being reflected back up, so the PIM silently stops being an accurate platform-neutral description. A well-known real-world lineage of this idea is **Executable UML (xtUML)**, which pushes the PIM far enough to be directly executable and simulatable before any PSM exists, letting teams validate business logic before committing to a platform — one of the more successful concrete applications of keeping the PIM genuinely platform-independent rather than a diagram-only intermediate step.