헥사고날 아키텍처 회고 (2)

2024. 7. 28. 21:57프로젝트/[EATceed] 몸무게 증량 어플

728x90

 

https://rasony.tistory.com/190

 

헥사고날 아키텍처 회고

EATceed 프로젝트에서 헥사고날 아키텍처를 사용해보며, 고민해본 점을 서술해보려고 합니다.먼저, 헥사고날 아키텍처를 도입한 이유입니다. 헥사고날 아키텍처를 도입한 이유 계층형 아키텍처

rasony.tistory.com

 

프로젝트를 진행하며, 외부 서비스를 이용해야하는 기능들이 점점 더 생기기 시작하였습니다.

 

구체적으로, AWS의 S3와 SES 서비스를 이용하고, 데이터베이스로는 MariaDB와 Redis를 사용하게 되었습니다.

또한, 특정한 트리거로 인한 스케줄링 기능을 사용하기 위해 Quatz를 도입하였습니다.

 

이에 아래와 같은 패키지가 추가되었습니다.

 

 

현재 패키지 구조는 도메인기반으로 패키지 구조를 나누고 있었습니다.

하지만, 이렇게 할 경우에 여러 도메인에서 하나의 외부서비스를 동일하게 이용해야할 경우 해당 외부 서비스를 어디에 둘 지가 애매했습니다.

그래서 결국에는 infrastructure 같은 패키지가 만들어지고, common 패키지 아래에 redisUtils 클래스가 만들어졌습니다.

 

하지만, 해당 패키지는 도메인 기반으로 패키지를 나눈 기존의 의도와 상충됩니다.

따라서, 패키지 구조에 대한 변화가 필요하였습니다. 이에 팀원과 패키지 구조에 대해서 이야기 하고 이를 정리해보고자 합니다.

 

infrastructure 패키지에 관하여

 

팀원과 첫 번째로 이야기한 주제는 infrastructure 패키지였습니다.

해당 패키지에 대해 이야기를 나누기 전에 팀원에게 제 의견을 잘 효과적으로 전달하기 위해 헥사고날의 구조와 각각의 의미에 대해서 설명하였습니다.

 

 

여기서 강조한 것은 External System Adapter의 의미였습니다. 
헥사고날은 마름모 안의 영역 즉 core를 변화로부터 지키기 위해 Port라는 통로를 만들어 외부와 연결합니다. 그리고 여기서의 외부는 데이터베이스와 AWS와 같은 외부 서비스입니다.


저희 시스템에서의 외부는 AWS와 MariaDB 그리고 Redis 마지막으로 Quatz 관련 코드라고 생각하였습니다.

따라서, 이들 관련 코드는 External System Adapter에 있어야합니다. 하지만, 외부 서비스는 여러 도메인에서 사용하고 있기에 각 도메인마다 똑같은 코드를 만들어야합니다. 이는 중복되는 코드가 생기므로 아예 패키지 구조를 내부와 외부를 더 잘 드러나게끔 수정하는 것을 제안하였습니다.

 

다음으로, infrastructure 패키지의 SSE 관련 코드입니다.

 

SSE(Server Side Event)의 경우 위의 패키지 구조와 같이 SSE 패키지를 따로 만드는 것이 아니라 SSE를 사용하는 도메인에 가서 해당 Web Adapter를 따로 만들어야 한다고 주장하였습니다.
왜냐하면, Input Port는 서버의 앞단 즉 클라이언트와 연결되는 통로를 추상화한 것이기때문에, 연결 방식이 Polling이든 SSE든 WebSocket이든 다 Input Port를 사용해 들어와야한다고 생각하였기 때문입니다.

 

따라서, 패키지 구조를 수정하였습니다.

 

변경 전 패키지 구조)

- member
	- adapter
		- in
		- out
	- application
		- port
			- in
			- out
		- UseCase 구현체
	- domain
	- exception

 

 

변경 후 패키지 구조)

- adapter
	- in
		- member
		- meal
		- food
	- out
		- redis
		- jpa
			- member
			- meal
			- food
		- aws
			- s3Adapter
			- SESAdapter
		- quartz
- application
	- port
		- in
			- usecase
			- XXXcommand
		- out
	- service
	- domain
		- Entity
		- VO

 

 

 

의견을 나누면서 가졌던 마음가짐 및 느낀점

 

상대방의 이야기를 잘 듣고 존중하고 있다는 것을 상대방이 충분히 인식할 수 있도록 노력하였습니다. (고개를 끄덕이는 행위 등)

 

또한, 의견을 나누는 행위가 누구의 의견이 맞고 틀리다를 결정하는 것보다는 서로의 발전에 도움이 되기 위해서 이러한 행동을 한다는 것을 팀원과 이야기하며 꾸준히 어필하였습니다.

 

또한, 주장을 할 때 정확한 예시와 근거를 들기 위해 노션에 제 의견을 정리하고 이를 이야기 전에 공유하였습니다.

 

마지막으로, 하나의 화제가 마무리 되면 다음 화제에 들어가기전에 각자 쉬는 시간을 가졌습니다.

 

이야기가 성공적으로 마무리될 수 있던 것은 위의 태도가 큰 역할을 하였다고 생각합니다.

앞으로도 이러한 상황이 있을 때 위와 같은 마음가짐을 가지고 이야기가 잘 마무리 될 수 있도록 노력해야겠습니다.

 

 

 

 

728x90