The Onion Architecture 도입 제안 및 고민되는 점

[queuedq]

코드베이스가 커지고 있으므로 저희 프로젝트의 아키텍처를 확실하게 정하고 넘어갈 필요가 있을 것 같습니다.
DB 접근, UI 등의 infrastructure를 애플리케이션의 중심 모델과 분리해서 unit-testable한 코드를 작성할 수 있는 The Onion Architecture 를 따르는 것을 제안합니다.

The Onion Architecture는 마치 양파처럼 여러 겹의 레이어로 구성되어 있고, 각 레이어는 더 안쪽의 레이어만을 참조하기 때문에 클래스간의 의존성 관리가 쉽다는 장점이 있습니다.

레이어는 안쪽부터 차례로 다음과 같습니다.

• Domain model: Movie, User 등 애플리케이션의 핵심적인 entity가 들어갑니다.
• Domain services: domain model에 접근할 수 있는 repository의 인터페이스가 들어갑니다.
• Application services: 평균 레이팅 구하기, 영화 추천 등 애플리케이션의 핵심적인 로직이 들어갑니다. (business logic)
• Infrastructure: DB 접근, UI 등 애플리케이션이 바깥 세상과 소통하기 위한 로직이 들어갑니다. DB 접근의 경우 domain services에서 정의한 repository 인터페이스를 구현하는 구현체를 통해 이루어집니다. Infrastructure는 언제든지 교체할 준비가 되어 있어야 하며 (e.g. DB 교체, UI 변경 등이 용이해야 함) 주로 라이브러리 함수들을 사용해서 간단한 연결만 하므로 유닛 테스트를 하지 않습니다. 대신 integration test를 합니다.

FAQ

Q. Infrastructure가 가장 바깥쪽에 있다면, 영화 추천에 사용할 영화 정보들을 어디서 구해야 할까요?
A. Dependency injection을 사용합니다. 영화 추천 메소드에서 repository 인터페이스를 따르는 오브젝트를 인자로 받도록 정의합니다. 그리고 infrastructure 쪽에서 (UI 쪽에서) 해당 메소드를 호출할 때 repository의 실제 구현체를 함께 넘겨줍니다. 굳이 이렇게 간접적으로 메소드를 구현하는 이유는, 유닛 테스트를 용이하게 하기 위함입니다. 만약 영화 추천 메소드가 직접 데이터베이스에 접근했다면 영화 추천 메소드를 테스트할 때 매번 데이터베이스에 연결하므로 유닛 테스트 시간이 오래 걸렸을 것이며, 데이터베이스 오류가 날 경우 유닛 테스트가 불가능할 것입니다.

Q. 이 프로젝트에서 UI에 해당하는 부분은 무엇인가요?
A. 유저의 입력을 command line argument로 입력받는 부분입니다. 해당 부분에서 application services에 정의된 실제 비즈니스 로직을 호출하게 될 것입니다.

고민되는 점

고민되는 부분이 있는데, MovieStorage 등이 domain model에 들어가야 하느냐 infrastructure에 들어가야 하느냐입니다. 각각에 대한 이유를 들어 보자면

infrastructure

• 주어진 .dat 텍스트 파일은 일종의 DB입니다. 애플리케이션의 핵심 로직과 관계 없고 바깥 세상과 연결해 주는 역할을 하고 있습니다.
• Repository의 in-memory 구현이라고 볼 수 있습니다.

domain model

• MovieStorage는 단순히 메모리에 영화를 추가하고 받아올 수 있는 저장 공간일 뿐이고, 실제 데이터를 넣는 것은 infrastructure 쪽에서 하고 있습니다.
• 때문에 유닛 테스트가 가능한 클래스입니다.

저희 과제에서 구현해야 하는 비즈니스 로직을 "텍스트 파일에서 영화 정보를 메모리에 로드하고, 로드한 정보를 바탕으로 영화를 추천한다"로 폭넓게 본다면 domain model에 들어가는 것이 타당하지만, "영화 정보는 바깥 세상(infrastucture)에서 아무튼 주어지고 주어진 정보를 바탕으로 영화를 추천한다"로 보면 infrastructure 로 보는 것이 맞습니다.

전통적인 방식에 따라 후자로 보되, integration test를 작성하는 것을 제안합니다.

[junwha]

말씀하신대로 Text 파일은 현재 일종의 DB이기 때문에 Infrastructre이 맞을 것으로 생각됩니다.
추천 알고리즘을 도입하면 DB도 필요해질 것 같은데,
piazza에 텍스트 파일의 내용을 DB로 옮기고 더 이상 load하지 않아도 되는지 여쭤본 뒤에 sqlite와 같은 가벼운 DB를 도입하는게 어떨까요?

[queuedq]

아직은 도입할 필요 없다고 생각하지만, 나중에 필요할지도 모르니 질문해 주시면 감사하겠습니다!

[junwha]

https://piazza.com/class/km1t4q5ekt33t4

[junwha]

Onion 아키텍쳐에서는 그러면 패키지 구조가 [Infrastructure].[Application services].[Domain services].[Domain model]
이렇게 되는건가요?

[queuedq]

자바 패키지는 코드 분리의 편의를 위함이므로 onion architecture에서 어떤 형태로 코드를 관리하라는 것에 대한 이야기는 하지 않습니다. 안쪽의 레이어에 의존한다는 것은 컨셉적인 부분이고, 각 패키지는 top-level에 정의하는 것이 좋겠습니다. #34 에 댓글로 한 가지 방안을 제안했습니다.

[junwha]

단순히 의존관계를 정의한거군요. 감사합니다!:)

[junwha]

추가 설명 자료: https://dev.to/barrymcauley/onion-architecture-3fgl

[junwha]

Application domain은 Repository의 interface에만 접근할 수 있다면, Repository의 구현체는 반드시 interface에 구현된 메소드만 사용해야겠네요?

[queuedq]

구현체에 다른 메소드가 들어가 있더라도 어차피 애플리케이션 레이어에서는 인터페이스에 정의된 메소드만 쓸 수 있어서 상관 없습니다. 물론 인터페이스에는 필요한 모든 메소드가 들어있어야 하겠죠.

[junwha]

답변 감사합니다! 그러면 이 아키텍쳐에서 인터페이스는 단순히 구현의 틀을 제공하는 것이 아니라 Polymorphism을 극대화하기 위한 장치로 사용되는거군요

[queuedq]

Polymorphism이라기보단 dependency inversion을 위해 사용된다고 할 수 있습니다. repository의 구현 디테일을 application service에 노출시키지 않기 위함입니다.

[junwha]

오오 좋은 정보 감사합니다!!!!:D