책임에 맞는 역할을 나누는 것과 효율성 🙌

TCA 아키텍처는 단방향 데이터 흐름으로 구현합니다. 모바일 앱을 개발할 때 단방향 데이터 흐름의 큰 장점은 복잡한 상태 및 동작을 다루는 데 있어서 좀 더 쉽고 신뢰할만한 코드를 만들어 낼 수 있다는 것입니다. 단방향 데이터 흐름에서 생길 수 있는 문제와 해결방법에 대한 이야기를 해보려고 합니다. TCA 아키텍처가 적용된 앱 화면에 음료수를 뽑을 수 있는 자판기가 보있습니다. 하나의 화면에 크게 두 가지의 역할이 보입니다. ☝️ 자판기 자판기의 역할은 진열된 음료수 중 재고가 있는지를 고객에게 보여주고 고객이 구매 버튼을 누르면 고객이 구매한 음료수를 주는 것 ✌️ 고객 고객의 역할은 음료수를 사기 위해 자판기에 돈을 넣고 원하는 음료수를 사기 위한 버튼을 누르는 것입니다. 자판기와 고객은 서로에 대해 알 필요가 없습니다. 자판기에서 음료수를 사기 위해 고객은 돈을 넣고 음료수를 뽑고 자판기는 음료수 가격만큼의 돈만 들어있다면 음료수를 주는 것이죠. 만약 하나의 Feature Domain에서 자판기와 고객을 모두 구현한다면 어떤 일이 생길까요? 자판기의 재고는 그대로인데 고객이 돈 5,000원을 넣었다는 이유만으로 자판기의 재고가 다시 그려져야 합니다. 또한 자판기에 콜라 재고가 없어서 재고를 채웠는데 이미 충분히 존재했던 초코우유의 재고가 다시 그려져야 할 수도 있습니다. 실제로 이렇게 의미 없이 다시 그려지는 화면이 많으면 많을수록 성능저하가 심하게 발생합니다. TCA에서는 하나의 FeatureDomain을 Store라는 객체로 관리합니다. Multi Store를 구현할 때 Scope 기능을 사용하여 하위 객체의 상태 및 동작을 노출할 수 있게 도와줍니다. TCA에서는 하나의 화면이 아무리 복잡해도 역할만 잘 분리된다면 협력할 수 있는 객체들로 잘 만들 수 있는 큰 장점이 있습니다. 그렇다면 Multi Store는 언제 사용할까요? 1️⃣ 성능 종속성 비교 트리를 제공하지 않는 단방향 데이터 흐름 아키텍처는 시스템을 통과하는 작업 비용이 지속해서 증가하므로 프로젝트가 커짐에 따라 결국 성능 문제가 발생합니다. 하나의 화면에 있는 여러 객체를 Multi Store를 구현하여 상태 공유를 최소화함으로써 성능 문제를 최소화할 수 있습니다. 2️⃣ API 캡슐화 Multi Sotre를 통해 객체 간 협력을 이룰 때 가장 중요한 것은 ‘내가 하는 것이 아닌 남에게 일하도록 시켜라’ 는 것입니다. Store 내부 구현은 다른 Store에게 노출되지 않고, 인터페이스도 매우 작아지기 때문에 테스트가 용이해지고 코드를 변경해야 할 떄 수정해야 할 객체가 최소화되기 때문에 증분 빌드에 도움이 됩니다. 3️⃣ 객체 지향 프로그래밍 Multi Store 아키텍처를 사용하기로 결정한 이상 객체 간의 의존성이 완전히 분리된 데이터 모델링이 엔지니어에게 요구됩니다. 아무리 아키텍처가 견고하고 역할 간 의존성이 잘 분리가 되어 있어도 데이터 모델링과 객체 간의 협력은 엔지니어의 몫입니다.