After splitting permit-review and fee-calculation into separate processes, developers propose a shared internal JAR of domain types so each side can call the other like a local method. What integration approach should replace that hidden coupling?
Select an answer to reveal the explanation.
Short Explanation
Once processes are separate, talk is a published letter—not rummaging through a shared desk drawer of types. Explicit network contracts stay versionable. Shared-kernel JARs smuggle compile-time coupling back in.
Full Explanation
After splitting permit-review and fee-calculation into separate processes, collaboration should go through explicit, versionable network contracts—documented request/response or events, commonly over HTTP-style APIs—rather than a shared internal JAR of domain types. Published contracts keep each side free to evolve internals and release on its own schedule. A shared kernel JAR smuggles compile-time coupling back in so every field change becomes a lockstep bump across services.
Keeping the shared kernel JAR and bumping it in lockstep on every field change recreates the monolith’s coordinated release problem across process boundaries. Writing directly to each other’s heap memory via a custom JNI bridge on the same host destroys isolation and portability. Requiring both services to import each other’s private source packages at compile time is even tighter coupling than a versioned JAR.
Exam caveat: inter-process integration is about versionable network contracts; this item is not an API Gateway policy-design deep dive.
Operational check: remove the shared domain JAR from both build paths, call through a documented HTTP or event contract, and verify one service can add an additive field without a forced same-day rebuild of the other.