In a layered Model-Driven Design approach, such as platform-independent versus platform-specific models, what does it mean for an abstraction layer to 'leak,' and why does that undermine the whole approach?
answer
- boundary failing between layers
- downward leak = platform detail in PIM
- upward leak = tech vocabulary in CIM
- kills retargetability
- not usually tool-enforced
basics
~20 sLeaking means details from a lower, more technical layer sneak into a higher, supposedly technology-neutral layer, like a database-specific trick showing up in the 'business' model, which defeats the whole point of keeping them separate.
solid answer
~50 sEach layer in a model-driven design — CIM, PIM, PSM — exists to hide a specific set of concerns from the layers above it: the PIM hides platform choices, the CIM hides software structure entirely. A leak is when a concern that belongs to a lower layer shows up in a higher one: a platform-specific optimization, say a denormalized column added purely for query performance on one database engine, gets modeled directly on the PIM, or a UI-widget detail creeps into the domain model. Once that happens, the higher layer is no longer actually independent of what it claims to be independent of — the 'platform-independent' model can no longer be safely retargeted to a different platform without also redesigning the leaked-in detail, and the layer separation stops delivering the reuse and clarity it promised while still costing the team the overhead of maintaining multiple layers.
go deeper
Should be able to give one simple example of a detail that doesn't belong at a given layer, such as a database table name in the business requirements.
Should explain both directions of leakage — platform detail creeping up, or business detail failing to stay separable from platform-specific detail — and why it defeats retargetability.
Should be able to describe a concrete detection or prevention practice their team uses or would use — review checklist, retargeting exercise, tooling stereotypes — not just define the problem.
Should be able to judge, for a given project, whether preventing leakage is worth the discipline cost versus deliberately collapsing layers, and set the org-level review practice that catches leakage before it compounds across many teams' models.
## Why the boundary has to hold Layered model-driven design only pays for itself if each layer genuinely doesn't know about the concerns the layer below it is responsible for. - The **Platform Independent Model** is valuable specifically because it can, in principle, be transformed into more than one Platform Specific Model. - The **Computation Independent Model** is valuable specifically because a non-technical stakeholder can review it without software vocabulary getting in the way. Both promises depend on a hard boundary holding. **Leaking** is the term for that boundary failing: a concept that properly belongs to a lower, more concrete layer gets modeled at a higher, supposedly more abstract layer, contaminating it with detail it was designed to exclude. ## Both directions of the leak Concretely, leakage happens in both directions of the MDA stack. - **Downward leakage into the PIM** looks like adding a database index hint, a caching annotation, or a specific serialization format to what's supposed to be a platform-neutral class diagram, because a developer needed a performance fix and it was faster to bolt it onto the PIM than to properly push it down into a PSM-level concern. - **Upward leakage into the CIM** looks like a requirements document that starts referencing 'the API' or 'the database' because whoever wrote it was thinking in implementation terms rather than business terms, at which point domain experts can no longer meaningfully review it. Either direction, the symptom is the same: someone opens a model expecting one kind of information and finds a different kind mixed in. ## Why it undermines the whole approach The reason this matters goes back to why the layers exist at all: **to let each concern change independently.** If a platform-specific optimization is embedded in the PIM, then a change of platform — the entire scenario the PIM/PSM split exists to make cheap — now also requires redesigning the supposedly platform-independent model, because it turns out it wasn't independent. The team is now paying the ongoing cost of maintaining separate CIM, PIM, and PSM artifacts, more diagrams, more transformation rules, more review overhead, without collecting the payoff of retargetability and stakeholder-reviewable requirements those extra artifacts were supposed to buy. This is strictly worse than not separating the layers at all, because at least a single unified model has only one place to maintain. ## How it accumulates Leakage is rarely a single dramatic event; it accumulates. 1. A developer under time pressure takes the path of least resistance and adds one platform detail to the PIM just this once. 2. Nothing catches it, because unlike a compiler, most modeling tools don't enforce the CIM/PIM/PSM boundary — it's a discipline, not a constraint the tooling checks automatically, though some UML-profile-based tooling does provide stereotype-level enforcement as the exception rather than the default. 3. Six months and a dozen just-this-once additions later, the PIM is full of platform assumptions nobody documented as such, and the first time the team actually tries to retarget it to a new platform, they discover the PIM has to be substantially rewritten, at which point someone reasonably asks why they bothered maintaining a separate PIM at all. ## Managing the boundary deliberately A concrete, well-known instance of managing this boundary deliberately is **Executable UML (xtUML)**: its whole premise is that the PIM must be executable and testable in complete isolation from any platform, with translation rules doing all the platform binding later, precisely so leakage is structurally harder — if the model can be simulated and produce correct behavior with zero reference to any platform API, platform detail literally cannot have crept in, because there's nothing platform-specific for it to call. Teams without that level of tooling rigor typically manage leakage the low-tech way: - code review checklists that explicitly ask whether a model change references any specific technology, and - periodic audits where someone tries to imagine retargeting the PIM to a second platform, specifically to surface hidden platform assumptions before they calcify.
- How would a team actually catch PIM-to-PSM leakage before it accumulates for months?The most reliable low-tech check is periodically asking whether this PIM element could be transformed to a second, different platform without modification, and specifically looking for anything that only makes sense for the current platform. Some teams enforce this with UML-profile stereotypes or tooling that flags platform-specific keywords, but absent that, it has to be an explicit code-review question, not an assumption.
- Is all leakage necessarily bad, or are there cases where blending layers is the pragmatic choice?If a project genuinely will never target a second platform and has no non-technical stakeholders reviewing the CIM, strict separation buys reuse and reviewability nobody will use, so a deliberate, documented decision to merge PIM and PSM, or skip a formal CIM, can be the right call. The danger isn't blending as a considered decision — it's blending by accident, where nobody decided to give up the separation but it happened anyway.
It's like a company org chart, meant to show reporting lines only, that someone starts scribbling desk locations onto — now the chart can't be reused when the office moves floors, even though who reports to whom never changed.
saying these in an interview costs you the question
- can't give a concrete example of what a leaked detail looks like
- thinks layer separation is purely about diagram organization, not reuse or review value
- assumes tooling automatically prevents leakage
- no answer for how a team would notice leakage happening