UseCaseArchitectureIssue

https://github.com/aafwu00/design_by_object/tree/master/cleancode7usecase 에 있는 내용에 대한 피드백

최범균 의견 (작성 중)

• 말을 쉽게 하기 위해 이렇게 말하면 어떨까요?: 인 바운더리 - 메커니즘 -> 인터랙터, 아웃 바운러디 - 인터랙터 -> 메커니즘
• 바운더리 이슈는 일반 GUI 어플리케이션의 경우 적용이 잘 될 것 같습니다. (리스너 등의 모델)
• 웹의 REQUEST/RESPONSE와 인/아웃 바운더리 인터페이스는 매칭이 잘 안 되는 것으로 보입니다.

제 생각에 웹에서는 아웃 바운더리는 인 바운더리의 요청으로 어떤 결과물을 받기 위한 인터페이스라 생각됩니다.

• Response Model을 그대로 아웃 바운더리를 이용해서 전달하는 경우라면, 인터랙터에서 리턴하는 방식으로 처리하는 게 쉬워 보입니다.
• 그런데, Response Model을 각 딜리버리 메커니즘 마다 알맞게 변환해서 받아야 한다면 아웃 바운더리가 출현해야 할 것으로 보이는데요, 이 때의 아웃 바운더리는 빌더 패턴의 모습을 따르면 좋을 것 같습니다.

위 빌더 패턴 적용은 아마도 아래와 같은 모습

-- 도메인 영역의 코드
public interface DomainDataBuilder<T> {
    public void addSome(..);
    public void addAny(..);
    public T build();
}
public class DomainData {
    public T build(DomainDataBuilder<T> builder) {
        builder.addSome(mySome.toString());
        builder.addAny(myAny);
        return builder.build();
    }
}
public class SomeInteractor implements SomeBoundaryIF {
    @Override
    public T service(Request req, DomainDataBuilder<T> builder) {
        DomainData result = doService(req);
        return result.build(builder);
    }
}

-- 딜리버리 메커니즘
public class SomeController {
    SomeBoundaryIF bundaryIF;
    public String some(...) {
        MyBuilder myBuilder = new MyBuilder();
        MyData data = boundaryIF.service(req, myBuilder);
        ...
    }
}

김광수 의견

• 저는 아직 스크린케스트를 못보았지만 태호님의 그림과 소스내용으로 미루어볼때, 범균님 의견대로 웹의 Request/Response와 인/아웃바운더리 인터페이스는 잘 안맞는것 같습니다. 그래서 저도 인터렉터에서 리턴하는 방식에 동의합니다.

• 인터렉터가 리턴하는 방식에서 여러가지 인/아웃 바운더리가 출현하는 상황을 클래스다이어그램으로 그려봤습니다.

• OrderController, AsyncOrderController, CreateOrderExecutor가 바운더리가 되고 OrderService가 인터렉터, DispatcherServlet 또는 PushNotifier가 딜리버리 메커니즘이 되지 않을까 합니다.

광수님 의견 피드백:

• (최범균) 여기서 (스프링) Controller는 딜리버리 메커니즘에 속한다고 생각되어, 바운더리 인터페이스는 아닌 것 같습니다.