UI层与领域层分离：领域层是否需依赖UI接口的技术问询

Great question—this is a super common pitfall when building layered systems after learning about the principles in Applying UML and Design Patterns. The short answer is: Absolutely not. The domain/logic layer should never have any direct knowledge of the UI layer. Doing so breaks core layered architecture rules like separation of concerns and dependency inversion, making your code harder to test, reuse, and maintain.

Let’s break down why this matters, plus clean, pattern-aligned ways to handle returning results to the UI without coupling the layers:

Why the Domain Layer Shouldn’t Depend on UI #

Layered architectures are built around this rule:

• Lower layers (domain/logic) hold business rules and core functionality, completely independent of how users interact with the system.
• Upper layers (UI) depend on lower layers, but never the other way around.

If your domain layer knows about UI interfaces, you’re creating tight coupling that causes problems:

• Changing the UI (e.g., switching from a desktop window to a web app) would force you to modify the domain layer.
• You can’t test the domain layer in isolation (you’d need to mock UI components just to run business logic tests).
• Reusing the domain layer in another context (like a backend API) becomes impossible without carrying unnecessary UI dependencies.

Clean Solutions to Return Results to UI #

Here are the most practical approaches for different scenarios:

1. Return Values (Synchronous Cases) #

For simple, fast operations like adding two numbers, the easiest fix is to have the domain layer return the result directly. The UI layer calls the domain method, receives the result, and handles updating itself.

Example code:

// Domain Layer (no UI references at all)
public class CalculatorDomain {
    public int add(int num1, int num2) {
        // Core business logic (even if simple here)
        return num1 + num2;
    }
}

// UI Layer
public class CalculatorWindow {
    private CalculatorDomain calculator = new CalculatorDomain();
    private TextField inputNum1;
    private TextField inputNum2;
    private Label resultDisplay;

    // Triggered when user clicks the "Add" button
    public void onAddButtonPressed() {
        int num1 = Integer.parseInt(inputNum1.getText());
        int num2 = Integer.parseInt(inputNum2.getText());
        
        // Call domain layer and get result
        int sum = calculator.add(num1, num2);
        
        // Update UI with the result (UI handles its own rendering)
        resultDisplay.setText(String.valueOf(sum));
    }
}

This keeps the domain layer pure and focused on logic, while the UI takes responsibility for presenting data.

2. Callback/Observer Pattern (Asynchronous Cases) #

If the domain operation is slow or runs in the background, use a callback interface to notify the UI when the result is ready. The domain layer only depends on an abstract callback, not the specific UI component.

Example code:

// Abstract callback interface (lives in domain layer or shared interface layer)
public interface CalculationResultListener {
    void onCalculationComplete(int result);
}

// Domain Layer
public class AsyncCalculatorDomain {
    public void addAsync(int num1, int num2, CalculationResultListener listener) {
        // Simulate long-running task in a background thread
        new Thread(() -> {
            int sum = num1 + num2;
            // Notify the listener when done
            listener.onCalculationComplete(sum);
        }).start();
    }
}

// UI Layer implements the callback
public class CalculatorWindow implements CalculationResultListener {
    private AsyncCalculatorDomain calculator = new AsyncCalculatorDomain();
    // ... UI components

    public void onAddButtonPressed() {
        int num1 = Integer.parseInt(inputNum1.getText());
        int num2 = Integer.parseInt(inputNum2.getText());
        
        // Pass the UI's callback implementation to the domain layer
        calculator.addAsync(num1, num2, this);
    }

    @Override
    public void onCalculationComplete(int result) {
        // Update UI (note: in real apps, switch back to the UI thread here)
        resultDisplay.setText(String.valueOf(result));
    }
}

Here, the domain layer doesn’t know anything about CalculatorWindow—it only knows about the CalculationResultListener interface. This maintains full separation.

3. Event Bus (Decoupled Communication) #

For complex systems, use an event bus to publish events from the domain layer, which the UI layer subscribes to. The domain layer publishes a "CalculationCompleted" event with the result, and the UI listens for that event to update itself. This is even more decoupled than callbacks, as the domain layer doesn’t need to know about any listeners at all.

Key Takeaway #

The core principle here is dependency inversion: depend on abstractions, not concretions. The domain layer should never rely on UI-specific types. By using return values, callbacks, or events, you keep each layer focused on its own responsibility, making your system more robust and adaptable.

内容的提问来源于stack exchange，提问作者Luai Ghunim