EBI 아키텍쳐에 대해서

Entity-Boundary-Interactor(EBI) 아키텍쳐는 Robert C. Martin의 Clean Architecture에서 언급되었다. 그런데 사실 EBI 아키텍쳐는 1992년 Ivar Jacobson의 Object-Oriented Software Engineering: A use case driven approach에서 먼저 등장하였다.

EBI Architecture - introduction to object types — *Ivar Jacobson 1992, pp. 1*69

Entity

Entity 객체는 시스템에서 사용되는 데이터들을 가지고 있고 시스템은 이 데이터를 통해 움직인다. Entity 객체는 도메인 문제를 해결하기 위해 존재하고 주로 Entity 객체는 identity를 가지고 있거나 persistent한 데이터를 가지고 있다.

Jacobson은 Entity 객체가 자신이 가진 데이터가 바뀌면 그에 따라 동작이 달라져야한다고 보았다. 예를 들어 어떤 시스템에서 사용되고 있는 자료구조가 바뀐다면 해당 자료구조에 맞춰서 시스템의 동작이 달라져야하고, 데이터가 달라짐에 따라 시스템의 동작이 달라지기 때문에 해당 자료구조와 그와 관련된 로직들은 Entity 객체 안에 담겨야 한다.

Jacobson이 1992년에 Entity 객체와 관련해서 다음과 같이 언급했다:

Beginners may sometime only use entity object as data carriers and place all dynamic behaviour in control objects […]. This should, however be avoided. […] Instead, quite a lot of behaviour should be placed in the entity objects.
Ivar Jacobson 1992, pp. 134

Boundary (Interface)

Boundary 객체는 시스템의 인터페이스를 정의한다.

[…] everything concerning the interface of the system is placed in an interface object
Ivar Jacobson 1992, pp. 134

외부 라이브러리 툴 혹은 데이터베이스, 메세지 큐와 같은 delivery mechanism들에 의존하는 모든 기능들은 Boundary 객체에 포함되어야한다.

Actor와 시스템의 상호작용은 Boundary 객체를 통해 일어나야한다. Jacobson은 Actor를 고객 혹은 관리자와 같은 사람으로 볼 수 도 있지만 알람, 프린터 혹은 외부 API와 같은 ‘사람이 아닌’ 것들도 있다고 보았다.

EBI Architecture - overview of Boundary object — Ivar Jacobson 1992, pp. 171

위와 같은 개념은 Ports & Adapters 아키텍쳐와도 밀접하게 연관이 있다. 그런데 Ports & Adapters 아키텍쳐는 무려 13년이 지난 2005년에 등장하였다.

Interactor (Control)

Interactor 객체는 Entity나 Boundary와 같은 다른 타입의 객체들이 할 수 없는 일을 한다. 예를 들어 Entity의 동작들과 Boundary 객체의 결과를 이어나감으로써 다른 큰 동작을 만들어 낸다.

Behaviour that remains after the Interface objects and Entity objects have obtained their parts will be placed in the control objects
Ivar Jacobson 1992, pp. 185

다시말해 Jacobson은 Entity 객체나 Boundary 객체가 할 수 없는 일들은 Control 객체에 담기게 된다고 말하고 있다. Control 객체는 여러 다른 객체의 동작들을 orchestrate할 뿐만 아니라 비즈니스 로직과 관련이 있지만 Entity나 Boundary 객체가 할 수 없는 일을 하게 된다.

DDD의 개념과 대조해보았을 때 Control 객체는 Application Service (도메인 객체들을 orchestrate 하는 역할)와 Domain Service(도메인 로직을 담고 있지만 Entity가 아닌 경우)의 역할을 한다고 볼 수 있다.

Interactor 객체가 중요한 이유는 만약에 우리가 Interactor 객체를 사용하지 않는다면 특정 use case의 비즈니스 로직을 Entity에 담게될 것인데 Entity는 본래 도메인 지식 내에서 다양한 상황에 쓰일 수 있도록 유연하게 설계되어야 한다.

Entity 객체에 특정 use case의 로직을 넣게 된다면 재사용율이 떨어질 것이고 이 Entity에 의존하는 다른 객체들의 로직들도 바뀌어야할 수도 있다. 따라서 전체 시스템의 복잡도를 증가시키게 된다.

Why 3 object types?

1992년 당시에 다른 OO 방법론에서는 모든 책임들과 로직들을 Entity 객체에 넣으려고 했었다. 하지만 Jacobson은 이 모든 책임들을 세 가지 타입으로 분류하여 각 책임들을 다른 타입의 객체에서 처리하고자 하였다. 결과적으로 이를 통해 좀 더 변화에 유연하게 바뀔 수 있는 시스템을 만들고자 하였다.

[…] all systems will change. Therefore stability will occur in the sense that all changes will be local, that is, affect (preferably) only one object in the system.
Ivar Jacobson 1992, pg. 135

EBI 아키텍쳐의 목표는 결국 서로 다른 타입의 객체들이 각자의 책임을 캡슐화를 함으로써 시스템에 변화가 필요할 때 그 변화가 시스템 전체에서 일어나지 않고 특정 부분에서만 바꿈으로써 문제가 해결될 수 있도록 하는 것이다.

이러한 철학은 10년 뒤에 Robert C. Martin의 “Agile Software Development, Principles, Patterns, and Practices“에서 언급한 Single Responsibility Principle 라고 알려져있는 원칙과 유사하다.

Conclusion

MVC 패턴에서 Model이 백엔드 시스템에서 모든 entity, service 그리고 그들의 관계를 나타내는 것처럼, EBI 아키텍쳐에서 Boundary는 view, controller 혹은 interface와 같이 외부에게와의 연결통로 역할을 하게 된다. 이는 MVC 패턴에서 View와 Controller의 역할을 한다고 볼 수 있다. 그리고 Entity는 실제 데이터를 가지고 있고 그와 관련해서 비즈니스 로직을 담고 있는 역할을 한다. 마지막으로 Interactor는 presentation 레이어와 Entity를 연결시키는 역할을 하는데 이는 Application Services와 Domain Service의 역할을 한다고 볼 수 있다.