S90-03 SOA Design and Architecture: Service Boundaries, Composition, and Governance

S90-03 is a historical exam identifier for SOA Design and Architecture. Unlike some older S90 codes whose numbering no longer aligns neatly with the modern curriculum, Arcitura’s current Service Technology School still includes Module 03, Design & Architecture with SOA, Services & Microservices. The source page therefore has a clear legacy-to-current subject bridge.

The design layer builds on the principles in S90-01 and the communication mechanics in S90-02. It asks how a set of services should be shaped into an architecture that can evolve, compose, scale, and remain governable. The central challenge is not drawing boxes; it is choosing boundaries and contracts that reduce the cost of future change.

Arcitura Education describes current design coverage in terms of service-oriented application design, service capabilities, composition roles, the eight service-orientation principles, REST and web-service guidelines, and microservice design. Candidates should use those themes to reinterpret the historical S90-03 page through modern distributed-system examples.

Architecture begins with business capabilities and change boundaries

A service boundary should align with a meaningful capability and with the people responsible for changing it. If two components always deploy together and share internal data structures, calling them separate services may add network complexity without real independence. If one component has a stable business purpose and a distinct rate of change, a service boundary may reduce coordination.

Candidates should practice identifying both functional cohesion and organizational coupling. Architecture is shaped by who owns the data, who approves changes, and how quickly different capabilities evolve. A technically elegant boundary that cuts across four teams can be harder to operate than a slightly less pure design with clear ownership.

Service contracts should expose intent rather than implementation

The contract is an architectural boundary. Consumers should see stable business concepts rather than internal storage tables, private class names, or temporary workflow states. This makes it possible to refactor implementation while preserving external behavior.

Versioning strategy should be decided before breaking change becomes urgent. Candidates should compare additive changes, parallel versions, compatibility adapters, and deprecation windows. The architecture should make consumer migration observable rather than leaving old clients indefinitely invisible.

Composition design must address partial success explicitly

A composition coordinates multiple capabilities into a larger outcome. The design should identify which participant controls the process, which steps can be retried, which side effects are irreversible, and how the system behaves if one service is unavailable after earlier work has succeeded.

Long-running business processes often cannot rely on a single distributed transaction. Compensation, reservation, state machines, and eventual consistency become architectural tools. Candidates should reason from business invariants: what must never happen, what can temporarily diverge, and how the system converges again.

Agnostic services and task services serve different design purposes

Agnostic capabilities are designed to be reusable across multiple processes, while task-oriented services can coordinate a specific business flow. The distinction helps avoid placing process-specific logic inside every reusable entity or utility capability.

Candidates should not force every service to be generic. Generalization has a cost in abstraction and governance. The question is whether reuse is likely and whether a stable context can be defined without compromising clarity. A well-designed task service can be exactly the right boundary for a workflow that has little reuse value.

Data ownership should follow service responsibility

Shared databases are one of the fastest ways to undermine service autonomy. When multiple services update the same tables directly, internal schema changes become cross-team breaking changes and business rules can be bypassed. Clear data ownership encourages changes to flow through contracts.

There are legitimate reporting, integration, and migration cases where data is replicated or shared, but the architecture should distinguish authoritative ownership from read models and copies. Candidates should be able to explain which service is the system of record and how other views stay synchronized.

Governance should constrain architecture without freezing it

Service inventories need naming, contract, security, versioning, and ownership standards. Without governance, every team invents incompatible approaches and discoverability collapses. With excessive governance, teams spend more time seeking approval than improving the system.

Effective governance defines a small set of enforceable principles and automates checks where possible. Architecture review should focus on consequential decisions—boundaries, shared data, public contracts, security, and resilience—rather than stylistic preferences that do not affect system behavior.

REST and microservice design should preserve service principles

Modern service design frequently uses HTTP APIs and independently deployed services, but the older SOA principles still provide useful tests. Is the contract standardized? Is coupling controlled? Can the service be composed? Is autonomy real? Is the interface discoverable and understandable?

A microservice that exposes dozens of chatty fine-grained calls may create worse coupling than a well-designed larger service. Candidates should avoid equating small code size with good architecture. The unit of design is the capability and its change boundary, not an arbitrary line count.

Operational architecture must include scaling and failure domains

Design is incomplete if it describes only the happy-path interaction. Candidates should identify which services can scale independently, where queues absorb bursts, how timeouts prevent resource exhaustion, and how failures are isolated. These concerns become deeper in the historical advanced material represented by S90-08.

The same applies to observability. Correlation, tracing, health checks, and ownership metadata should be designed into the system because post-hoc instrumentation is harder once many services are in production. Architecture should make failure understandable, not merely survivable.

Architecture labs should force competing constraints

A useful exercise is to design an order, claims, booking, or onboarding process with several reusable capabilities. Then change the constraints: one capability moves to another team, one step must become asynchronous, a consumer needs a new contract version, and one service must continue during a downstream outage. The later S90-09 lab-oriented material is built around this kind of applied reasoning.

Candidates should document which principles drove each choice and which trade-off was accepted. A design is stronger when it can explain why a boundary exists and what future change it protects against. Diagrams are evidence of reasoning, not a substitute for it.

S90-03 is best studied by repeatedly translating architecture principles into change scenarios. A system that looks clean on a static diagram can still be tightly coupled through databases, deployment pipelines, identity, or operational ownership. The design must be tested against how the organization actually changes software.

The historical page remains useful because the core design vocabulary survives in Arcitura’s current curriculum, now expanded to services and microservices. Candidates should use current examples while preserving the original concern with standardized contracts, loose coupling, composability, autonomy, and deliberate service boundaries.

A strong design answer does not claim that one architecture is universally correct. It states the required business outcome, identifies the constraints, shows how the service model addresses them, and names the costs that remain. That is the durable architectural judgment behind S90-03.

Candidates should also design for policy boundaries. Some services handle regulated or high-risk data and require tighter authentication, audit, retention, or approval than neighboring capabilities. Grouping everything behind one broad service account can erase those boundaries even when the service diagram looks clean. Architecture should make sensitive transitions explicit so that controls can be reviewed and tested.

Data synchronization patterns deserve special attention when services own separate stores. Change data capture, domain events, scheduled reconciliation, and query-time federation each create different freshness and failure characteristics. A candidate should avoid declaring that data is “eventually consistent” without defining the acceptable delay and the process that detects when convergence has failed.

Finally, think about deletion and lifecycle, not only creation. What happens when a customer is removed, a contract version reaches end of life, or a service is replaced? Orphaned events, stale read models, and forgotten credentials are common sources of operational and security debt. A service architecture is mature when it has a retirement path for capabilities and data as well as a launch path.

Design reviews should also ask where synchronous call depth becomes dangerous. A user request that crosses many sequential services accumulates latency and creates a long chain of availability dependencies. Sometimes the correct redesign is not faster networking but a different composition boundary, precomputed read model, or asynchronous step that removes unnecessary runtime coordination.

Candidates should also distinguish logical availability from infrastructure availability. A service can be running and reachable while unable to complete its business function because a dependency, data source, or policy system is unavailable. Architecture should define health from the capability perspective and should avoid declaring success merely because a process responds to a basic probe.

A strong architecture review should end with explicit invariants: which service owns each business fact, which contracts must remain backward compatible, where synchronous latency is acceptable, where eventual consistency is allowed, and which failures must be isolated. Once those invariants are written down, patterns can be evaluated against them rather than selected because they are familiar. Introduce a change such as a new channel, a new regulatory boundary, or a high-volume partner and ask whether the existing composition still holds. This forces the design to demonstrate adaptability while preserving clear responsibility. It also helps distinguish a service-oriented architecture from a collection of networked components that happen to expose endpoints but lack coherent ownership and governance.