How to Evolve Business Architecture: Service Boundaries, Splitting, and Governance

Business Architecture Evolution

Business architecture continuously evolves as the organization grows, often reflected in the way business domains are divided. The evolution brings service and module boundary problems that need practical solutions.

From Functional to Domain Splitting

Initially, services were split by functionality, which was simple, intuitive, and adhered to the single‑responsibility principle, enabling rapid iteration. As the business expanded, a shift to domain‑based splitting became necessary, exposing code coupling and unreasonable dependencies that affected system stability and development efficiency.

Service Grading

Services are classified into four grades (P0‑P3) to guide prioritization, dependency inversion, and resource planning:

P0: System‑level foundational services; outages cause widespread impact.

P1: Core business services; outages affect primary business flows.

P2: Non‑core business applications and auxiliary functions.

P3: Internal support services such as operation back‑ends.

Basic Principles for Service Layers

Lower‑level services must not directly call upper‑level services.

Stability of lower‑level services must not be limited by upper‑level services.

Services on the same level should maintain logical isolation as much as possible.

Base services provide only fundamental capabilities and keep their models stable.

Boundary Problems and Solutions

Code Coupling : Shared code and cross‑domain responsibilities cause owners to modify code for other teams, leading to schedule disruption and release dependencies.

Unreasonable Dependencies :

Reverse dependency – lower layers depend on upper layers.

Cyclic dependency – services depend on each other forming a loop.

Strong vs. weak dependency – services that should be independent become tightly coupled.

Technical Practices

Splitting : Separate services with no shared code directly; extract shared base capabilities into libraries or independent services; handle shared business logic via aggregation services when necessary.

On‑Demand Loading + Weak Dependency Degradation : Classify dependencies as weak (main flow can continue) or strong (main flow blocked). Provide fallback or degradation for weak dependencies.

GraphQL for Data Assembly : Use GraphQL to query atomic data units on demand, reducing the need for numerous dedicated APIs and supporting flexible data formats.

Boundary Changes : Re‑evaluate domain boundaries to reduce P0 services, keep stable models together, and ensure clear business meaning.

Domain Model Optimization : Store cross‑domain data in KV tables and update asynchronously via events, decoupling models and eliminating strong coupling.

Capability Push : Move non‑core functionalities from low‑level models to higher‑level services, reducing risk to critical services.

Event‑Driven Architecture : Broadcast lifecycle events so upstream services can react independently, ensuring idempotent message delivery and providing compensation mechanisms for failures.

Asynchronous Calls : Replace direct calls with asynchronous event‑driven components, allowing timeout handling and distinguishing strong vs. weak dependency modes.

Anti‑Corruption Layer : Isolate third‑party or external team code in a dedicated layer to prevent contamination of core services.

Conclusion

Splitting, on‑demand loading, weak‑dependency degradation, boundary changes, and event‑driven techniques are effective entry points for service governance. However, deeper issues often require costly domain‑model refactoring, so teams resort to anti‑corruption layers, capability push, and asynchronous calls to achieve practical progress without endless delays.