클린 아키텍쳐 (공통 모듈)

각 핵심서비스에서 공통적으로 사용할 기능 및 모듈은 어떻게 설계에 포함해야 하는지 알아봅시다.

지난 시간에는 각 핵심 서비스는 Tuist를 이용하여 핵심 서비스를 나누고, 각 핵심 서비스에서는 개발을 더욱 편리하게 하기 위해 Preview를 만들어 그곳에서 개발하며, 통합 App로 각 핵심 서비스를 연동하는 방법에 관해 기술하였습니다.

이번 시간에는, 각 핵심 모듈에서 공통으로 사용하는 기능, 네트워크 서비스에 관해 이야기하고자 합니다.

지속이 가능한 서비스를 위해 저는 클린 코드를 모바일 앱에 맞게 다시 각색하여 사용하였습니다. 먼저 대 전제(설계 사항) 부터 정리하겠습니다.

  • 내부 레이어는 상위/외부 레이어의 어떤 것도 알아서는 안 된다
  • 각 레이어간의 데이터 전달은 Entity를 이용하여 UseCase로 전달하고 응답받아야 한다.
  • 레이어 간의 데이터 전달은 Pure Swift여야만 한다.

대전제에서 고려해야 할 큰 부분은 바로, 아키텍처에서는 프레임워크 또는 외부 라이브러리에 의존하지 말아야 합니다. 의존하기 시작한다면, 그 아키텍쳐의 수명은 프레임워크의 지원 여부에 달려 있을 수 있으며, 다른 개발자들 또한 해당 프레임워크 학습에 대한 시간이 충분히 확보되어야 합니다.

사용처에서는 프레임워크 또는 외부 라이브러리에 의존하지 말아야 합니다. 의존하기 시작한다면, 그 아키텍쳐의 수명은 프레임워크의 지원 여부에 달려 있을 수 있으며, 다른 개발자들 또한 해당 프레임워크 학습에 대한 시간이 충분히 확보되어야 합니다.

Application은 세부 기능에서 데이터 커뮤니케이션은 도메인으로 전달한다

세부적인 이야기는 아래에 더 다루도록 하겠습니다. 일단 데이터 간의 커뮤니케이션을 어떤 방식으로 해야 하며 그렇게 하기 위해서는 어떤 방식으로 구성해야 하는지부터 설명해보도록 하겠습니다.

먼저 도메인이라는 영역이 있습니다. 도메인은 데이터의 모델링(Entity), 데이터 간의 커뮤니케이션 방법(UseCase)만 가지고 있습니다. 화살표의 흐름대로 도메인은 플랫폼에 대한 정보를 절대로 알면 안 됩니다. 반대로 플랫폼이라는 영역에서는 도메인에 대한 정보는 알 수 있지만 의존성 주입 컨테이너에 대한 정보를 알면 안 됩니다.

여기서 한 가지 흥미로운 사실은 의존성 컨테이너와 응용프로그램과의 관계인데, 의존성 컨테이너에 응용프로그램은 예를 들어 (라이브, 개발, 모킹 등등) 플래그를 주게 됩니다. 그럼 의존성 컨테이너는 그에 걸맞은 도메인의 구현 객체를 전달합니다. 하지만 응용프로그램은 플랫폼에 대한 정보는 알아서는 안 됩니다.

전달받은 도메인을 응용프로그램은 내부에서 도메인 영역의 정보로만 비즈니스 로직을 수행하게 됩니다.

도메인

먼저, 도메인의 목적은 데이터 간의 커뮤니케이션을 보다 명시적으로 전달하기 위한 목적입니다.

위의 도식 표는 도메인에 회원가입, 로그인, 사용자 정보에 필요한 데이터모델과 대상 모델을 어떻게 사용해서 가져오는지 대한 정의부(Protocol / Interface)로 나뉘게 됩니다.

플랫폼

플랫폼은 먼저 도메인을 import 받습니다. 즉 도메인을 알고 있다는 것이죠. 각각의 Core에는 커뮤니케이션을 위한 다양한 서비스가 내부적으로 존재하게 됩니다. 그리고 Core를 이용하여 Domain의 내부 구현체를 구현하는 것입니다.

DI-Container(의존성 주입 컨테이너)

응용프로그램이 설정 값 또는 내부 설정에 따라 다르다

의존성 주입 컨테이너는 응용프로그램의 요구사항에 따라, 플랫폼의 구성 요소를 다양하게 조합하여 응용프로그램에 전달하게 됩니다.

Application (응용프로그램)

응용프로그램은 의존성 주입 컨테이너에 현재 자신이 실행하고자 하는 컨테이너를 만들어달라고 요청합니다.

요청한 컨테이너를 받고 각 패키지 모듈로 의존성을 주입하고 패키지에서 의존성 모듈로 페이지 모듈을 생성하게 됩니다.

이번 시간에는 클린아키텍쳐를 통해서 레이어별 담당과 데이터 간의 커뮤니케이션에 대해 알아봤습니다.

추가로 암호화 알고리즘, 복잡한 연산의 경우를 담당하는 기능 또한 레이어로 나누어 공통으로 쓰이면 어떨까? 라는 피드백을 받았습니다. 해당 공통 연산 및 유틸리티 기능은 Domain과 동일한 영역으로 나누어서 UseCase로 쓰기에는 너무 과하다는 생각에 Domain만 이용하여 공통적인 기능을 구현하였습니다.

이와같이 구현체는 해당 링크에 올려놨습니다.

다음 시간에는 SwiftUI 기반 MVI 아키텍쳐 에 대해 알아보도록 합시다.

0 Shares:
You May Also Like
Read More

각 핵심서비스의 독립

대부분의 앱의 첫 출시는 내부의 기능과 콘텐츠들은 매우 심플하고 복잡하지 않습니다. 그러나 사업이 확장되고, 더 많은 서비스가 등장하고,…
Read More

SwiftUI 기반 MVI(TCA) 아키텍쳐

일단 여기서 언급하는 아키텍쳐는 클린아키텍쳐도, 모듈 기반 아키텍쳐도 아닌, 별개로 보셔도 됩니다. 먼저 안드로이드와 iOS의 비즈니스 로직을 동일하게…