Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

Version 1 Current »

Feature B의 Port와 Inbound Port

구조

  • Feature B는 자신의 비즈니스 로직(Service)을 노출하기 위해 Port를 작성합니다.

  • Feature A는 Feature B의 Port를 통해 필요한 기능을 호출합니다.

  • 이때, Feature B의 Port는 **Feature B 내부(Core)**로 들어오는 요청을 처리하므로, Feature B 입장에서는 Inbound Port로 간주됩니다.

[Feature A] ---> [Feature B's Port (Inbound)] ---> [Feature B's Core Logic]

예시 코드

Feature B의 Inbound Port 정의

Feature B는 자신이 제공하는 비즈니스 기능을 추상화하여 Port로 정의합니다.

// Feature B의 Inbound Port
public interface FeatureBPort {
    String performBusinessLogic(String input);
}

Feature B의 Port 구현

Feature B의 Service를 사용하여 Port의 메서드를 구현합니다.

// Feature B의 Port 구현체
@Service
public class FeatureBPortImpl implements FeatureBPort {
    private final FeatureBService featureBService;

    public FeatureBPortImpl(FeatureBService featureBService) {
        this.featureBService = featureBService;
    }

    @Override
    public String performBusinessLogic(String input) {
        return featureBService.businessLogic(input);
    }
}

// Feature B의 내부 Service
@Service
public class FeatureBService {
    public String businessLogic(String input) {
        return "Processed: " + input;
    }
}

Feature A에서 Feature B의 Port 호출

Feature A는 Feature B의 Port를 주입받아 호출합니다.

// Feature A의 Service
@Service
public class FeatureAService {
    private final FeatureBPort featureBPort;

    public FeatureAService(FeatureBPort featureBPort) {
        this.featureBPort = featureBPort;
    }

    public String useFeatureB(String input) {
        return featureBPort.performBusinessLogic(input);
    }
}

3. Feature A 입장에서의 Port의 역할

Feature A 관점

  • Feature A는 Feature B의 Port를 호출하여 Feature B의 내부(Core) 기능에 접근합니다.

  • 이 Port는 Feature B의 진입점 역할을 하므로, Feature B의 Inbound Port로 간주됩니다.

Feature B 관점

  • Feature B의 Port는 외부에서 들어오는 요청을 처리하여 자신의 비즈니스 로직(Service)을 호출하는 역할을 합니다.

  • 따라서, 이 Port는 Feature B의 Inbound Port입니다.

4. 장단점

장점

  1. Feature 간 결합도 감소:

    • Feature A는 Feature B의 Service 구현체가 아닌 Port 인터페이스를 통해 접근하므로, 두 Feature 간 결합도가 낮아집니다.

  2. 유연성 증가:

    • Feature B의 Port를 Mocking하여 Feature A에서 독립적으로 테스트 가능.

  3. Feature B의 응집력 유지:

    • Feature B의 비즈니스 로직은 Port를 통해서만 접근 가능하므로, Feature B의 응집력을 유지할 수 있습니다.

단점

  1. 복잡성 증가:

    • 각 Feature 간 상호작용을 위해 Port와 Adapter를 작성해야 하므로 초기 설계가 복잡해질 수 있습니다.

  2. Feature 간 간접 의존성:

    • Feature A는 Feature B의 Port 인터페이스에 의존하게 되어, Feature B가 제거되거나 변경될 경우 간접적으로 영향을 받을 수 있습니다.

5. 결론

  • Feature A에서 Feature B의 Service를 접근하도록 Feature B가 Port를 작성한 경우, 그 Port는 Feature B의 Inbound Port로 간주됩니다.

  • 이 설계는 Feature 간 결합도를 줄이고, Feature B의 비즈니스 로직을 캡슐화하는 데 유용합니다.

  • 다만, Feature 간의 상호작용이 많아질 경우, Port와 Adapter가 많아질 수 있으므로 설계 복잡성을 관리해야 합니다.

  • No labels