헥사고날 아키텍처란
들어가며 사내에서 진행하는 새로운 프로젝트를 진행하였는데요, '새롭게 발생하는 요구사항에 빠르게 대응하기 위해 확장성 있게 설계하자'는 목표가 있었습니다. 따라서 목표에 맞게 팀 스터
cantcoding.tistory.com
이번주 저희 회사 테크리드 분께 우연히 Hexagonal Architecture에 대해 설명을 듣게 되었습니다.
설명을 듣자마자 "와.. 이거 기획할 때 엄청 중요하고 반드시 알아야 하겠는데?" 란 생각이 들어 블로그로 작성하게 되었습니다.
Hexagonal Architecture는 소프트웨어 개발방법론 중 하나로 클린 아키텍처를 구현하는 가장 대표적인 모델입니다. 사실 PO,PM이 이렇게 딥하게 알 필요까지는 없을 것 같지만, 여기가 반드시 기억해야 할 부분은 개발자와 이야기 나누기 전 혹은 문제를 정의할 때 반드시 도메인 영역(비지니스 로직 영역)에 대한 깊은 고민이 선행되어야 한다는 점입니다. 또한 각자의 영역이 어디까지인지를 명확히 알 수 있다는 점입니다.
보통 기획을 할 때 어떤 것을 해결할지(문제 정의)를 중심으로 필요한 것들을 작성하는데 문제 정의를 잘 하더라도 서비스 운영에 필요한 것을 놓치기 쉽습니다. 이는 회사에서 기획을 할 때는 사용자 중심 뿐만 아니라 기술 구현 관점, 운영 관점까지 고민을 해야 하는데 다각도로 생각하는 습관보다는 사용자 중심으로만 생각하는 습관이 있기 때문입니다.
예를 들어 내가 회사에서 개발자와 소통이 조금 어렵고 나는 한 가지만 이야기 했는데 개발자들이 여러 줄기를 이야기한다 느껴진다면 혹은 내가 기획안 다 작성했는데 개발자들이 개발은 안한다고 한다면 기술 구현 관점, 운영 관점에서 놓치고 있는 부분이 있을 가능성이 매우 높습니다.
위 블로그에 소개된 사례인 주문 관리 서비스를 만든다고 할 때 도메인은 주문인 것이고 각각 필요로 하는 서비스(기능)가 주문 등록, 주문 전송, 배송 준비, 주문 저장, 주문 조회 등등이 된다는 것입니다. 그래서 만약 주문 관리를 기획한다 하면 주문관리 중 주문 등록만 고민하면 안되고 주문 관리 전체 프로세스를 먼저 고민하고 그 다음 세부적인 것에 대해 고민을 해나가야 합니다.
개인적으로는 단순히 기획하는 사람이 혼자서 이 모든 것을 고민할 필요는 없다 생각합니다. 도메인을 먼저 정의하고 필요한 서비스들이 무엇이 있는지 초안정도만 작성한 뒤 바로 개발자와 소통해도 기획하는데 큰 도움을 받을 것입니다. 결국 기획이라는 것은 혼자 하는 것이 아니고 제품은 같이 만드는 것이기 때문입니다.
짧게 작성되었지만 많은 분들에게 도움이 되었으면 합니다~!
디스코드 커뮤니티 안내
PM & PO 직군의 취직, 이직, 커리어를 같이 이야기할 디스코드를 운영 중에 있습니다. 그 외 많은 정보가 디스코드에 있으니 많은 관심 부탁드립니다.