아키텍처 개선에 대한 고민

초기 프로젝트

원래 아키텍처는 위와 같은 모습이었다.

첫번째 개선

첫번째 개선에서는 다음과 같은 일을 했다.

 

서비스 간 의존 결합도를 줄이기 위해 인터페이스 도입

각 서비스가 인터페이스를 통해 상호 참조될 수 있도록 하여 결합도를 낮췄다. 이를 통해 서비스 간의 결합도를 낮추고 유연성을 높였다.

PhotoService의 재사용성을 높이기 위해 역할 분리

PhotoService의 재사용성을 높이기 위해 EncryptionService에 의존적이었던 메소드를 삭제하고, Encryption 관련 역할과 책임을 PhotoService에서 분리했다. 이를 통해 PhotoService는 더욱 독립적이고 재사용 가능하게 만들었다.

EncryptionService의 역할 재정의

암호화 역할을 명확히 하기 위해 Encryption을 Service에서 Component로 변경했다. 이를 통해 암호화 관련 기능을 더욱 독립적으로 관리하고, 서비스 계층의 복잡성을 줄였다.

 

첫번째 개선을 통해 얻을 수 있었던 이점은 다음과 같다.

 

결합도 감소

인터페이스 도입으로 서비스 간 결합도가 낮아져 각 서비스가 독립적으로 변경될 수 있는 유연성이 생겼다.

재사용성 향상

PhotoService가 독립적이게 되어 다른 서비스에서도 재사용할 수 있게 되었다.

유지보수 용이성

EncryptionService의 역할 재정의로 인해 암호화 관련 기능이 명확히 분리되어 유지보수가 쉬워졌다.

두번째 개선

두번째 개선에서는 다음과 같은 일을 했다

 

1:1 관계였던 Photo와 Snap을 단일 Entity로 정리

Snap과 Photo가 1:1 관계였던 것을 단일 엔티티로 통합하여 데이터 모델을 단순화하고, 시스템 복잡성을 줄였다. Encryption과 User 또한 1:1이지만 도메인 복잡도와 관리상의 이유로 이를 통합하지 않았는데, 앞으로 어떻게 해야 할지 고민이다.

File Component 추가

PhotoService의 역할을 파일 시스템 CRUD로 제한하고, 이를 FileComponent로 변경하여 서비스 계층에서 제외시켰다. 이를 통해 각 컴포넌트의 역할이 명확히 분리되고, 재사용성과 모듈화가 강화되었다.

SnapService와 Encryption Component 간의 상호작용

SnapService가 Encryption Component와 직접 상호작용하여 데이터 암호화 작업을 명확히 했다.

명확한 컴포넌트 분리

Encryption Component와 File Component가 명확히 분리되어 독립적인 개발과 테스트가 용이해졌다.

 

두 번째 개선을 통해 얻을 수 있었던 이점은 다음과 같다.

 

데이터 모델 단순화

Snap과 Photo를 단일 엔티티로 통합하여 데이터의 모델을 단순화하고 시스템의 복잡성을 줄였다.

성능 최적화

서비스 계층에서 파일 시스템 관련 기능을 분리함으로써 성능을 최적화할 수 있었다.

독립적 개발 가능

각 컴포넌트가 명확히 분리됨으로써 독립적인 개발과 테스트가 가능해졌다.

 

아키텍처 개선을 통해 전체적인 시스템이 더 모듈화 될 수 있었고 유지보수성이 높아졌으며, 각 구성요소의 역할이 명확하게 정의되었다. 결과적으로 시스템의 확장성과 유연성도 크게 향상될 수 있었다.