BLoC의 가장 큰 문제는 “BLoC” 이라는 이름입니다.
저는 BLoC을 정말 좋아합니다.
상태 관리 플러그인으로서, BLoC은 말썽꾸러기 문제아인 getX 와는 아예 비교하고 싶지도 않고, provider 시리즈에 비교해서도 몇 가지 확실한 장점들이 있습니다.
패턴으로서의 BLoC 또한, 안정적이고 굳건한 코드를 작성할 수 있도록 해주는 점이 좋습니다.
하지만 BLoC이라는 이름은 몇몇 플러터 개발자들에게 혼동을 줍니다.
Business Logic Component. 비즈니스 로직을 담고 있는 컴포넌트?
먼저 Business Logic 의 일반적인 정의를 내리고 가야할 것 같네요.
우리가 일반적으로 생각하고 있는 Business Logic은 무엇입니까?
(https://en.wikipedia.org/wiki/Business_logic)
위키피디아의 정의는 아래와 같습니다.
In computer software, business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, stored, and changed. It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program.
데이터를 생성, 저장, 변화시키는 프로그램의 영역을 의미하죠. 이것이 일반적인 정의입니다.
Business Logic 을 제외한 다른 부분들. 데이터베이스를 저수준으로 다루는 디테일한 부분들, UI 보여주기, 시스템 인프라, 프로그램의 다른 부분들을 일반적으로 연결하는 것과는 구분됩니다.
간략화된 클린 아키텍처 방식으로 Presentation — Domain — Data 3단계 레이어로 나누었을때, Business Logic 은 일반적으로 Domain 레이어에 속합니다.
원조 4단계 레이어에서 이야기하는 Business Rules 은 Use Cases 레이어와 Entities 레이어에 있습니다. 단지 Enterprise wide 하냐, application specific 하냐 정도의 차이가 있습니다.
Entities
Entities encapsulate Enterprise wide business rules.
Use Cases
The software in this layer contains application specific business rules.
물론 레이어 정의는 주관적일 수 있습니다. 정해진 법이나 규칙이 있는 것은 아니죠. 따라서 보는 시각에 따라 다른 레이어에서도 Business Logic 을 담을 수 있다고 생각할 수 있습니다. 네, 좋아요. 좋습니다. 하지만 확실한 것은 Domain 레이어는 Business Logic 을 담고 있습니다.
그러면 BLoC 에서 주장하는 Business Logic(이하 BL) 은 무엇입니까?
이 문단을 보면 알수 있듯이,
The business logic layer’s responsibility is to respond to input from the presentation layer with new states. This layer can depend on one or more repositories to retrieve data needed to build up the application state.
Think of the business logic layer as the bridge between the user interface (presentation layer) and the data layer. The business logic layer is notified of events/actions from the presentation layer and then communicates with repository in order to build a new state for the presentation layer to consume.
BLoC 에서의 BL의 정의는 일반적이지 않은 정의를 내리고 있습니다.
첫 문단에서는 BLoC 이 그저 프레젠테이션 레이어에서 입력을 받아서 반응하는 책임만을 가지고 있습니다. 레포지토리들에서 App State 를 구성하기 위한 데이터를 불러오죠.
두번째 문단을 보면 갑자기 Business Logic 레이어를 프레젠테이션 레이어와 데이터 레이어를 연결하는 다리로 생각하자라고 합니다. Presentation 레이어와 Data 레이어? 웬 Data Layer?
그러면 BLoC 클래스는 Domain 레이어와 동치됩니까? 왜 첫 문단과 다른 이야기를 합니까? 왜 이렇게 우리를 헷갈리게 하나요?
아까 보았던 위키피디아의 정의를 다시 보죠.
It is contrasted with the remainder of the software that might be concerned with lower-level details of managing a database or displaying the user interface, system infrastructure, or generally connecting various parts of the program.
프로그램의 다른 파트들을 일반적으로 연결해주는 것을 BL 에서 제외하고 있는 위키피디아의 정의와는 완전히 상충되고 있습니다.
그 문단 아래쪽에 있는 그림을 보면 결국 BLoC은 Application Layer(?) 에 속해있습니다.
우리가 좀 전에 봤던 Presentation — Domain — Data 구조에서 Presentation 과 Domain 레이어 사이에 BLoC 레이어를 만들어 놓고 있죠.
하지만 결국 일반적인 3단계 구조로 생각했을 때 Presentation 레이어에 속합니다. Application 레이어를 Presentation 이라고 생각해도 아무런 문제가 없습니다. 그림의 윗부분에도 App-Domain-Data 로 나누어져 표시되어 있듯이 BLoC은 3단계 구조에서 Domain 이 아니라 다른 레이어에 속합니다. BLoC은 Domain 레이어에 속하지 않는다고요.
그러면 왜 위 그림에 BLoC 부분에 Business Logic 이라고 썼을까요?
그건 BLoC에서 정의한 BL에 따라서 저 부분이 BL이기 때문입니다. 이상하죠?
우리가 지금까지 내린 결론은 다음과 같습니다.
Domain 레이어는 Business Logic 을 담고 있습니다.
BLoC(Business Logic Component) 은 Domain 레이어에 속하지 않습니다.
이러한 모순이 생깁니다.
둘 중 하나는 문제가 있겠죠. 그리고 그건 일반적인 정의에 있는 것이 아니라 BLoC 에서의 BL 정의에 있다고 생각하는 것이 자연스러울 겁니다.
그러면 왜 이런 특수한 정의를 하고 있을까요?
제가 생각하기에는 그건 단순히 이름 때문입니다. BLoC 플러그인을 만든 Felix Angelov 도 죄가 없습니다. 단지 BLoC 이라는 패턴을 명명한 사람이 문제가 있는 것입니다. 비즈니스 로직이라는 단어가 들어가면 안됐습니다.
어쨌든 BLoC 에서의 Business Logic 은 개발자들이 일반적으로 생각하는 것과는 차이가 있습니다.
그러니 우리 BLoC에 우리의 일반적인 Business Logic 을 모두 담지는 말아요.
#블록패턴 #블록아키텍처 #상태관리 #블록단점
