处理横切关注点
实现日志记录、身份验证和授权策略，同时不违反依赖规则，也不污染核心逻辑。
处理横切关注点 是 CoddyKit 上的免费 Clean Architecture & Design Patterns in Practice 课时。 这是第 1 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Clean Architecture & Design Patterns in Practice 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Clean Architecture & Design Patterns in Practice 课程共包含 4 节课。
本课时的部分内容尚未翻译，以英文显示。
What are Cross-Cutting Concerns?
In software development, cross-cutting concerns are aspects of a system that affect many parts of the application but are not part of its core business logic. Think of them as system-wide services.
- Logging: Recording events for debugging or auditing.
- Authentication: Verifying a user's identity.
- Authorization: Determining what an authenticated user can do.
- Caching: Storing frequently accessed data for faster retrieval.
- Transaction Management: Ensuring data consistency across multiple operations.
The Clean Architecture Dilemma
Clean Architecture emphasizes keeping your core business logic (Entities and Use Cases) independent of external frameworks and delivery mechanisms. This is enforced by the Dependency Rule: dependencies must only flow inwards.
The challenge arises because cross-cutting concerns often rely on specific external frameworks (e.g., a logging library, a security framework). How can we implement these concerns without violating the Dependency Rule and coupling our core logic to external details?
Logging Without Pollution
Let's take logging as an example. If a CreateUserUseCase directly calls a logging framework like Log4j or SLF4J, it creates a dependency on that specific framework.
CreateUserUseCase → Log4j
This violates the Dependency Rule because the inner layer (Use Case) would depend on an outer layer (Frameworks/Drivers). Our core logic should not care how logs are written, only that they need to be written.
Defining a Logging Port
To solve this, we introduce an interface in our inner (Use Case) layer. This interface, often called an Output Port, defines the contract for logging. The Use Case depends on this abstraction, not a concrete implementation.
package application.ports;
public interface ILogger {
void info(String message);
void error(String message, Throwable t);
}Implementing the Logger Adapter
The actual logging framework implementation lives in an outer layer (e.g., Infrastructure). This concrete class acts as an Adapter, implementing our ILogger port and delegating to the specific logging library.
Notice how ConsoleLogger depends on ILogger (an inner layer abstraction), respecting the Dependency Rule.
package infrastructure.logging;
import application.ports.ILogger; // Depends on inner layer
public class ConsoleLogger implements ILogger {
@Override
public void info(String message) {
System.out.println("[INFO] " + message);
}
@Override
public void error(String message, Throwable t) {
System.err.println("[ERROR] " + message + " - " + t.getMessage());
}
}Logger in a Use Case
Now, our CreateUserUseCase can depend on the ILogger interface. The concrete ConsoleLogger is injected at runtime, typically by a Dependency Injection (DI) container, but we'll do it manually here for clarity.
package application.usecases;
import application.ports.ILogger;
import infrastructure.logging.ConsoleLogger;
public class CreateUserUseCase {
private final ILogger logger;
public CreateUserUseCase(ILogger logger) {
this.logger = logger;
}
public void execute(String username) {
logger.info("Attempting to create user: " + username);
// ... business logic to create user ...
logger.info("User created successfully: " + username);
}
}
public class Main {
public static void main(String[] args) {
// Manual Dependency Injection for demonstration
ILogger consoleLogger = new ConsoleLogger();
CreateUserUseCase useCase = new CreateUserUseCase(consoleLogger);
useCase.execute("Alice");
}
}Handling Authentication
Authentication (verifying who a user is) should occur at the application's entry points, not within the core Use Cases. The Use Case should only receive already authenticated user information.
- Middleware/Filters: In web applications, these intercept requests before they reach controllers.
- Input Port Decorators: You can wrap a Use Case with a decorator that handles authentication before delegating to the actual Use Case.
This ensures the Use Case remains focused on business logic, free from security framework details.
Authorization with Policies
Authorization (what an authenticated user can do) is often more complex. While basic authorization can also be handled at the entry point, more granular checks might involve the Use Case.
- Authorization Policies: Define separate objects or services that encapsulate authorization rules.
- Interceptors/Aspects: Apply these policies around Use Case execution, checking permissions before the core logic runs.
- The Use Case might depend on an
IAuthorizationServiceinterface (another Port) to query specific permissions.
DI for Cross-Cutting Concerns
The overarching principle for handling cross-cutting concerns in Clean Architecture is the Dependency Inversion Principle (DIP).
- High-level modules (Use Cases) should not depend on low-level modules (frameworks).
- Both should depend on abstractions (interfaces).
- Abstractions are defined in the inner layers, and their concrete implementations reside in the outer layers, injected at runtime.
This keeps your core logic clean, testable, and independent of external technologies.
Applying Clean Concerns
Consider a ProcessOrderUseCase that needs to log critical steps. Which approach aligns best with Clean Architecture's Dependency Rule?
Recap: Keeping Core Clean
We've explored strategies to handle cross-cutting concerns like logging, authentication, and authorization within Clean Architecture:
- Abstract Concerns: Define interfaces (Ports) in inner layers for concerns like logging.
- Implement Adapters: Provide concrete implementations of these interfaces in outer layers (Adapters).
- Boundary Handling: Use middleware, decorators, or interceptors at application boundaries for authentication and authorization.
- Dependency Inversion: This principle is crucial for ensuring your core business logic remains clean, independent, and free from external framework details.
常见问题解答
「处理横切关注点」课时是免费的吗？
是的 — 「处理横切关注点」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Clean Architecture & Design Patterns in Practice 课程的其余内容，请升级到 CoddyKit PRO。 Clean Architecture & Design Patterns in Practice 课程共包含 4 节课。
「处理横切关注点」这节课中我会学到什么？
实现日志记录、身份验证和授权策略，同时不违反依赖规则，也不污染核心逻辑。 你通过在浏览器中直接运行的动手代码来练习 Clean Architecture & Design Patterns in Practice，全天候 AI 导师会在你学习这节课的过程中回答你的问题。
学习 Clean Architecture & Design Patterns in Practice 需要有经验吗？
无需任何先前经验。CoddyKit 上的 Clean Architecture & Design Patterns in Practice 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 1 节课，共 4 节。
「处理横切关注点」课时需要多长时间？
大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。
我能在这节 Clean Architecture & Design Patterns in Practice 课中编写并运行代码吗？
能。每节 Clean Architecture & Design Patterns in Practice 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。