AEM OSGi Service Architecture: Boundaries, Configuration and Testability.

Start from behavior that needs independent testing or ownership, such as content lookup or an external API call. A bundle boundary and a service boundary are related decisions, but they do not need to be identical.

When a model owns request parsing, repository access, remote calls and error mapping, changes become hard to isolate. Configuration assumptions can also remain invisible until a service fails to activate in another environment.

Use Sling Models for presentation-facing data, application services for use-case behavior and adapters for external dependencies. Declare OSGi references and configuration expectations explicitly rather than locating dependencies ad hoc.

Define interface inputs, outputs and failure semantics before binding an implementation. Validate required configuration and handle lifecycle changes deliberately, without storing request-specific state in shared service instances.

• Keep external client details behind a replaceable adapter.
• Review required versus optional references against actual fallback behavior.
• Test service logic separately from model adaptation and runtime activation.

An optional reference avoids one activation constraint but moves responsibility into application logic. Define what callers receive when the dependency is unavailable rather than silently returning incomplete data.

Not every method needs a service interface. Introduce boundaries where they isolate a real dependency, business contract or lifecycle concern, and keep simple transformations easy to follow.

For a version-specific application of these boundaries, see LTS service activation and compatibility assessment.

Unit tests and container-level verification answer different questions.

• Test dependency failure and configuration edge cases through the interface.
• Verify expected reference and activation behavior on the target AEM baseline.
• Exercise Sling adaptation with representative request and resource inputs.

Readable interfaces describe what happens when configuration or dependencies are absent. That clarity supports upgrades and diagnostics without turning this page into either an upgrade guide or an incident playbook.

These sources document product behavior. The design and validation approach above are engineering proposals, not claims made by the vendors.

• OSGi: Declarative Services specification
• Apache Sling: Sling Models and exporters