Cross-Cutting Concerns

A cross-cutting concern is behaviour that many parts of a system need, but that is not the main purpose of any of them. Logging, security checks, transaction management, auditing, metrics, tracing and caching are typical examples. If each class implements them by hand, the same code is duplicated across the system and mixed into business methods, which makes both harder to change. For example, changing the audit format would mean editing hundreds of methods. Frameworks such as Spring let you declare these concerns once and apply them consistently, so business code stays focused on business rules and policies can change in one place.

At start-up, Spring's bean post-processors inspect each bean. If a bean has methods annotated with, for example, @Transactional or @Cacheable, Spring wraps it in a proxy, either a JDK dynamic proxy for interfaces or a CGLIB subclass, and injects that proxy wherever the bean is used. The proxy holds a chain of interceptors, also called advice. When a caller invokes a method through the proxy, the interceptors run in order, starting a transaction or checking a cache, then call the real method, and finally commit, roll back or store the result. Calls from inside the same object bypass the proxy.

Authentication, establishing who the caller is, is normally handled once at the boundary, for example by Spring Security's filters for HTTP requests or by the messaging infrastructure for messages, so it is not a service-layer concern. Authorisation, deciding whether that caller may perform a specific operation, is a cross-cutting concern that should also be enforced at the service layer. Services can be invoked from several entry points, such as REST controllers, message listeners, scheduled jobs and batch processes, and only some pass through web security. Annotations such as @PreAuthorize on service methods protect business operations whatever the entry point.

Ask two questions. First, is it a uniform policy that should apply the same way to many methods, such as starting a transaction, recording a metric or writing an audit entry? Second, is it independent of the business purpose of those methods? If both answers are yes, an aspect or annotation-driven interceptor fits well. If the behaviour contains business rules, varies by use case, or needs detailed knowledge of the method's data, it belongs in domain or application code, where it is visible and testable. A useful warning sign is an aspect that inspects arguments to decide what to do; that is usually business logic hiding in infrastructure.

A concern can be applied at several layers, and the right one depends on what information it needs. At the HTTP boundary, servlet filters and handler interceptors see requests and responses, which suits authentication, correlation IDs and request logging. At the service layer, AOP proxies see business method calls and arguments, which suits transactions, method security and auditing of business actions. At the data-access layer, repository interceptors and JPA entity listeners suit auditing of changes. Messaging interceptors handle the same needs for message flows, and infrastructure instrumentation such as Micrometer and OpenTelemetry covers metrics and tracing across all of them.

Make auditing a platform capability rather than something each team builds. Publish an internal Spring Boot starter that provides a standard @Audited annotation or domain-event mechanism, a shared audit event schema with fields such as actor, action, target, outcome and correlation ID, and a reliable delivery path, typically a transactional outbox feeding a central audit store. Teams add the starter and annotate business actions; the starter handles formatting, delivery and retries. Enforce adoption with architecture tests and pipeline checks, review audit coverage during design reviews, and version the schema carefully, because auditors and compliance tools will depend on it for years.

Cross-cutting concerns are where consistency matters most, so they should be delivered as platform capabilities rather than reimplemented by every team. Internal Spring Boot starters can provide security, logging, metrics, tracing and auditing defaults; API gateways can handle authentication, rate limiting and TLS at the edge; a service mesh can provide mutual TLS and retries between services; and a shared observability stack collects the results. This reduces each team's effort, makes behaviour consistent across services and lets policies, such as a new logging format or security rule, change centrally. Teams still own business concerns, while the platform owns the cross-cutting ones.