After splitting permit-review and fee-calculation into separate pro…

Question

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?

Accepted Answer

Collaborate through explicit, versionable network contracts such as documented request/response or events, commonly over HTTP-style APIs. — 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.

Answer

Keep the shared kernel JAR and bump it in lockstep across every service on every field change.

Answer

Write directly to each other’s heap memory via a custom JNI bridge on the same host.

Answer

Require both services to import each other’s private source packages at compile time.

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?

Short Explanation

Full Explanation