DEV Community

Cover image for Shared Business Logic Across Mobile, Backend, and Web
Vaibhav Shakya
Vaibhav Shakya

Posted on

Shared Business Logic Across Mobile, Backend, and Web

“Share the business logic” is incomplete architectural advice.

Before creating a common library, teams should answer three questions:

  • Which behaviours must remain consistent?
  • Which implementations are genuinely portable?
  • Which system owns the authoritative decision?

These concerns overlap, but they are not interchangeable.

What Is Worth Sharing?

The strongest sharing candidates are small, deterministic, and independent of infrastructure.

Examples include:

  • Pure pricing calculations
  • Date-boundary rules
  • Domain state machines
  • Money and percentage types
  • Reason codes
  • Versioned policy evaluations
  • Conformance test cases

Their inputs, arithmetic, rounding, and failure behaviour must be explicitly defined.

Contracts should also have a versioned source of truth. Generated transport models can reduce transcription errors, but they do not automatically solve compatibility, rollout order, or unknown-value handling.

Shared test vectors provide another option. Every platform can run the same inputs and expected outputs without consuming the same runtime library.

What Should Remain Platform-Specific?

Platform integration should normally remain close to its environment.

Secure storage, background execution, browser lifecycle, database transactions, navigation, notifications, and retry scheduling operate under different constraints.

A common interface can describe the capability required by the domain, while each platform retains control of its implementation.

Client Logic Is Not Backend Authority

Clients can calculate provisional prices, validate inputs, and determine which actions appear available.

The backend must independently evaluate security-sensitive and financially important decisions using current authoritative state.

A client may be outdated, modified, offline, missing recent events, or racing with another request. Sharing the same code does not make its inputs trustworthy.

When client and backend results differ, the backend should return:

  • A stable reason code
  • The applicable policy version
  • The updated domain state

The client should then reconcile its interface with the authoritative outcome.

Version Skew Must Be Designed For

Browser and backend deployments can move faster than installed mobile releases. Multiple client and policy versions may remain active simultaneously.

A compatibility strategy should define:

  • Versioned policies
  • Unknown-state handling
  • Supported older clients
  • Prediction-mismatch monitoring
  • Safe fallback behaviour
  • Retry and idempotency semantics

Choose the Right Sharing Mechanism

A shared source library works when participating platforms can adopt the same ecosystem and the logic remains portable.

Generated code works well for contracts and constrained models.

Independent implementations with shared conformance tests work well when toolchains and release processes differ.

The objective is not maximum shared code. It is minimum costly divergence without sacrificing authority or platform autonomy.

Read the complete architecture discussion, implementation example, failure scenario, and practical checklist:

Read the complete article

Top comments (0)