모든 시스템은 행동(Behavior)과 구조(Structure)의 두 가지 요소를 제공합니다. 행동은 시스템이 돈을 벌거나 돈을 절약하는 방식이며, 구조는 시스템을 수정하는 데 얼마나 용이한지를 의미합니다. 이 두 가지 요소는 독립적이지 않으며, 서로 밀접하게 연관되어 있습니다.
프로젝트 관리자(PM)나 고객이 새로운 기능을 요구하는 경우, 우리는 이 새로운 기능을 시스템에 추가해야 합니다. PM이나 사용자가 보았을 때, 구조를 아무리 잘 짜더라도 아웃풋이 같다면 굳이 이런 고민을 할까요? 이는 장기적으로 보아야 합니다. 만약 프로젝트의 코드가 스파게티 코드처럼 엉켜 있다면, 기능을 추가하기 위해 여러 부분을 수정 및 추가해야 할 것입니다. 반면에 구조가 통일되고 기능별로 코드가 잘 나뉘어 있는 프로젝트라면, 앞의 경우보다 할 일이 줄어들고, 좀 더 빠르게 요구를 만족시킬 수 있을 것입니다. 빠르게 임무를 끝낼 수 있다는 것은 그만큼 인건비가 줄어든다는 것을 의미합니다. 이는 시스템이 커질수록 그 차이가 더욱 커질 것입니다.
위 그래프를 보면 알다시피 아무리 좋고 유지보수하기 좋은 구조라 하더라도 한계가 명확한 프로잭트에 힘들게 구조를 넣을 필요는 없습니다. 그렇다고 구조를 넣지 말라는 말은 아닙니다. 적절한 구조를 찾고 적용해야합니다. 중간에 프로젝트의 구조를 바꾸는 어렵기 때문에 이는 우선적으로 진행되어야 합니다.
그렇다면 구조는 어떻게 구성해야 할까요?
이러한 질문은 예전부터 있어왔던 논제입니다. 현재는 SOLID나 컴포넌트 응집성이나 결합도 같은 여러 원리와 규칙들을 바탕으로 대표적인 아키텍처들이 나왔습니다. 이러한 아키텍처들의 공통점 중 하나는 비즈니스 로직에 집중해야 한다는 것입니다. 여기서 비즈니스 로직은 데이터를 생성, 표시, 저장, 변경하는 부분을 의미합니다. 이러한 비즈니스 로직은 시스템의 핵심 기능을 담당하며, 이를 잘 구성하는 것이 중요합니다.
비즈니스 로직은 다른 여러 부분에서도 필요로 합니다. 그 말은, 만약 이 로직을 변경하게 되면, 이 로직을 사용하는 다른 부분들에도 영향을 미치게 됩니다. 따라서 비즈니스 로직을 분리하는 것이 중요합니다. 대부분의 아키텍처는 비즈니스 로직을 어떤 방식으로 분리할 것인지에 따라 그 종류가 바뀝니다.
안드로이드에서는 권장하는 앱 아키텍처가 있습니다.
위 그림을 보면 계층형(Layered) 아키텍처와 매우 유사합니다.
계층형 아키텍처는 각 계층에 고유한 임무를 정의하여 구현하고, 데이터를 얻기 위해 각 계층에 바로 접근하는 것이 아니라 각 계층을 경유하여 데이터를 접근 및 수정할 수 있습니다. 또한, 고유한 임무를 정의했기에 사용자의 이벤트를 감지하는 곳이 따로 있어 해당 계층을 통해 흐름이 시작됩니다. 이러한 점은 유지보수나 로깅이 쉬워 개발에 도움을 줍니다.
안드로이드에서 권장하는 아키텍처도 이와 비슷합니다.
각 UI, Domain, Data 레이어가 있어 해당 레이어마다 각각의 역할을 지정받습니다.
- UI 레이어 : 사용자와 상호작용하는 부분으로, 사용자 입력을 처리하고 데이터를 표시합니다.
- Domain 레이어 : 비즈니스 로직을 처리하는 부분으로, 데이터 변환 및 비즈니스 규칙을 관리합니다.
- Data 레이어 : 데이터 소스와의 상호작용을 담당하며, 네트워크나 데이터베이스에서 데이터를 가져옵니다.
안드로이드는 이러한 구조에 추가로 DI나 디자인페턴의 적용을 권유하고 있습니다.
reference
https://www.youtube.com/watch?v=TqY1mnLBCVk&t=1177s
https://www.youtube.com/watch?v=4E1BHTvhB7Y
https://www.linkedin.com/pulse/what-design-stamina-hypothesis-how-does-apply-your-marcelo-marsson
https://www.youtube.com/watch?v=g6Tg6_qpIVc
https://developer.android.com/topic/architecture?hl=ko
