Clean Architecture & Design Patterns in Practice · บทเรียน

อธิบายกฎการพึ่งพา

ทำความเข้าใจกฎการพึ่งพาพื้นฐาน ซึ่งกำหนดให้การพึ่งพาไหลเข้าสู่ศูนย์กลางได้เท่านั้น เพื่อให้ตรรกะทางธุรกิจหลักแยกเป็นอิสระ

อธิบายกฎการพึ่งพา เป็นบทเรียน Clean Architecture & Design Patterns in Practice ฟรีบน CoddyKit นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Clean Architecture & Design Patterns in Practice และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Clean Architecture & Design Patterns in Practice มีบทเรียนทั้งหมด 4 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

The Core of Clean Architecture

Welcome to our lesson on the Dependency Rule! This principle is the cornerstone of Clean Architecture, ensuring your core business logic remains isolated and independent.

It's all about directing the flow of dependencies in your application in a very specific way.

Dependencies Flow Inwards

The fundamental idea is simple: dependencies can only flow inwards. This means outer layers of your architecture must depend on inner layers, but inner layers must never depend on outer layers.

Think of it as a one-way street, always leading towards the center of your application's logic.

Visualizing the Rule

Recall the concentric circles of Clean Architecture (Entities, Use Cases, Interface Adapters, Frameworks/Drivers). The Dependency Rule dictates that code in an outer circle can depend on code in an inner circle, but never the other way around.

Inner layers: Core business rules, independent.
Outer layers: UI, databases, web frameworks, external services.

Why This Rule Matters

Strictly following the Dependency Rule brings significant benefits:

Isolation: Your core business logic is protected from changes in UI, databases, or frameworks.
Testability: You can test your core logic without needing to set up a database or a web server.
Flexibility: You can swap out external components (e.g., change from SQL to NoSQL, or from one web framework to another) with minimal impact on your core.

Outer Layer Calling Inward

This is the natural and allowed flow. An outer layer, like a web controller, depends on an inner layer, like a Use Case, to perform an action. The controller knows about the use case.

Try running this example:

class CreateUserUseCase {
  public void execute(String username) {
    System.out.println("Logic to create user: " + username);
  }
}

// Outer layer (e.g., Web Controller)
class UserController {
  private final CreateUserUseCase createUserUseCase;

  public UserController(CreateUserUseCase useCase) {
    this.createUserUseCase = useCase;
  }

  public String register(String username) {
    createUserUseCase.execute(username);
    return "User registration initiated for " + username;
  }
}

public class Main {
  public static void main(String[] args) {
    CreateUserUseCase useCase = new CreateUserUseCase();
    UserController controller = new UserController(useCase);

    System.out.println(controller.register("Alice"));
  }
}

Inner Layer Independence

Now, what if our CreateUserUseCase (inner layer) needs to send a success message back to the UserController (outer layer)?

It cannot directly call a method on the UserController. That would mean the inner layer depends on the outer layer, breaking the Dependency Rule!

Inverting the Dependency

To solve this, we use Dependency Inversion. The inner layer (Use Case) defines an interface (often called a 'Port' or 'Output Port') that it expects to communicate through.

The outer layer (Controller/Presenter) then implements this interface and provides itself to the inner layer. This reverses the flow of dependency at compile time.

Code: Inverted Dependency

Observe how the CreateUserUseCase now depends only on its own interface, UserOutputPort. The UserController implements this port, allowing the Use Case to 'talk back' without knowing the specific UI details.

Try running this example:

// 1. Inner layer defines its 'output port' (interface)
interface UserOutputPort {
  void presentUserCreationResult(String message);
}

// 2. Inner layer (Use Case) depends on its own interface
class CreateUserUseCase {
  private final UserOutputPort outputPort;

  public CreateUserUseCase(UserOutputPort outputPort) {
    this.outputPort = outputPort;
  }

  public void execute(String username) {
    // Simulate user creation logic
    System.out.println("Processing creation for: " + username);
    outputPort.presentUserCreationResult("User '" + username + "' created!");
  }
}

// 3. Outer layer (e.g., Web Controller) implements the 'port'
class UserController implements UserOutputPort {
  private final CreateUserUseCase createUserUseCase;

  public UserController() {
    // Controller provides itself as the output port
    this.createUserUseCase = new CreateUserUseCase(this);
  }

  public void registerUser(String username) {
    createUserUseCase.execute(username);
  }

  @Override
  public void presentUserCreationResult(String message) {
    System.out.println("UI Update: " + message);
  }
}

public class Main {
  public static void main(String[] args) {
    UserController controller = new UserController();
    controller.registerUser("Bob");
  }
}

Consequences of Breaking the Rule

Violating the Dependency Rule leads to a fragile and rigid architecture:

Tight Coupling: Your core logic becomes tied to external details (UI, DB).
Difficult Testing: Testing business rules requires setting up external components.
Reduced Flexibility: Changing frameworks or databases becomes a massive undertaking.
Leaky Abstractions: Inner layers expose knowledge of outer layers, making the system harder to understand and maintain.

Quick Check

The Dependency Rule is crucial for maintaining a clean and flexible architecture. Let's test your understanding of how dependencies should flow.

Recap: The Dependency Rule

You've learned that the Dependency Rule is the core principle of Clean Architecture, dictating that dependencies must always flow inwards, from outer layers to inner layers.

It protects your core business logic.
It enhances testability and flexibility.
Dependency Inversion (using interfaces) is key to allowing inner layers to communicate outwards without direct dependencies.

Mastering this rule is essential for building robust and maintainable software systems!

คำถามที่พบบ่อย

บทเรียน “อธิบายกฎการพึ่งพา” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “อธิบายกฎการพึ่งพา” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Clean Architecture & Design Patterns in Practice ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Clean Architecture & Design Patterns in Practice มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “อธิบายกฎการพึ่งพา”

ทำความเข้าใจกฎการพึ่งพาพื้นฐาน ซึ่งกำหนดให้การพึ่งพาไหลเข้าสู่ศูนย์กลางได้เท่านั้น เพื่อให้ตรรกะทางธุรกิจหลักแยกเป็นอิสระ คุณปฏิบัติ Clean Architecture & Design Patterns in Practice ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Clean Architecture & Design Patterns in Practice หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Clean Architecture & Design Patterns in Practice บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน

บทเรียน “อธิบายกฎการพึ่งพา” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Clean Architecture & Design Patterns in Practice นี้ได้ไหม

ได้ บทเรียน Clean Architecture & Design Patterns in Practice ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

← กลับไปที่ Clean Architecture & Design Patterns in Practice