다음 코드를 살펴보겠습니다.
이 코드는 상태 변수 sinceLast가 옵저버블의 컨텍스트 외부에 존재할 수 있게 잘못 설계된 범위 관리의 예입니다. 잘못 설계된 범위 때문에 옵저버블은 더 이상 무상태(stateless)가 아니며 상태의 수명 주기와 옵저버블은 이제 상호 의존하게 됩니다.
옵저버블을 생성할 때 생태계 또는 제한된 컨텍스트를 생성한다는 것을 이해해야 합니다. 이 생태계는 구독으로 시작하여 구독 해제로 끝나는 폐쇄형 반복입니다. FP 관점으로 옵저버블을 살펴보면 옵저버블의 내부는 완전히 무상태로 유지되고 나머지 애플리케이션과는 어느 정도 분리된다는 것을 알 수 있습니다. 따라서 연산자에 전달되는 콜백의 범위는 작고 지역적이어야 합니다. 외부 부가 작용이 있는 코드를 혼합하면 추적하기 어려운 복잡성이 생길 뿐만 아니라 옵저버블을 사용할 때 얻을 수 있는 주요 장점 중 하나가 없어지게 되는데, 이는 잘 정의된 수명입니다. 옵저버블의 생성 및 폐기 시 시스템은 동일한 상태로 유지되어야 합니다.
제한된 컨텍스트가 무엇인가요
제한된 컨텍스트(bounded context)는 단일 도메인 모델과 관련된 엔터티는 응집력이 있어야 하며 다른 컨텍스트와 상호 작용하는 데 필요한 인터페이스만 표시해야 한다는 도메인 기반 디자인 패턴에서 비롯된 디자인 원칙입니다. 이 정의를 확장해 옵저버블에 적용해 보면, Observable 타입은 옵저버블을 통해 전달되는 데이터의 특성을 숨기는 컨텍스트 형태라고 볼 수 있어 외부 세계에서 일어나는 일들과 무관하게 노출되는 한정된 연산자 집합으로 구성된 유비쿼터스 언어(ubiquitous language)를 가지고 옵저버블을 변환할 수 있습니다.