아키텍처의 본질

우리는 왜 아키텍처를 필요로 할까?

이 질문에 대답하기 위해서 나는 3년하고도 2주가 필요했다

대학시절에는 아키텍처에 대해 존재, 관심조차 없었고
직장생활을 하면서 계층형 아키텍처에 대해 인지는 하였지만 ‘다들 쓰니까..’ 생각하며 깊게 고민해보지 않았다

하지만 2주전 코더의 탈을 벗어버리고자 시작한 과외, 엔지니어로서 첫 발걸음을 때고나서 많은 생각을 하게된 이후 아키텍처를 다시 바라보았다

아키텍처는 왜 필요로 하는가?
우리는 왜 개발을 하는가?

중요한건 개발이 아니였다

우리가 작성하는 코드가 결국 무엇을 위해 존재하는가 그 답을 찾아가며 그에 대한 해답의 실마리가 보이기 시작했다

** 우리의 코드는 왜 필요할까?

이전 게시글에서 가볍게 이야기했지만 개발에 대해서 다시 이야기해보고자 한다

나는 개발을 이렇게 생각한다

우리가 해결하고자 하는 문제를 찾고 그 문제를 해결하는 방법

결국 개발의 핵심은 문제를 해결하는 방법, 비즈니스 로직이라고 생각한다

카카오톡은 소통하기 어려운 문제를 해결하고자 나왔다 배달의 민족은 배달 시켜먹기 어려운 문제를 해결하고자 나왔다 토스 뱅크는 어려운 은행 송금, 은행 시스템을 해결하고자 나왔다 당근은 중고 거래의 어려운 문제를 해결하고자 나왔다

모두 문제를 해결하고자 시스템이 만들어졌고 출시되었고 시장의 반응을 얻었다

만약 카카오톡에서 메시지 전송 로직이 무너진다면? 배달의 민족에서 배달 주문 로직이 흔들린다면?

그 서비스는 유지되기 어렵다

비즈니스 로직은 서비스의 핵심인 것이다

아키텍처랑 비즈니스 로직이랑 무슨 상관인데?

그렇다면 아키텍처란 무엇일까?

아키텍처는 우리의 핵심 비즈니스를 지키기 위한 설계라고 생각한다

계층형이든 헥사고날이든 그건 방법의 차이일 뿐이다

결국 본질은 우리의 도메인을 외부로부터 지키는 것이다

여기서 도메인이란 우리의 핵심 비즈니스를 말한다

카카오톡의 메시지 전송,
배달의 민족의 주문 처리,
토스의 송금 서비스,
당근의 중고 거래

그 서비스가 존재하는 이유

그게 도메인이라고 생각한다

도메인은 왜 지켜야 할까?

이전 직장에서 게시글 목록을 조회하는 기능을 만들었다

Service에서 JPA@Entity 객체와 Pageable 객체를 그대로 받아 쓰고있었다

기능상으로 문제는 없었다

만약 그때 DB를 MongoDB로 바꿔야 했다면?

DB 하나를 바꾸는 건데 Service, Controller 전부 수정해야 했을 것이다

우리의 비즈니스가 달라진게 아니었다

외부가 바뀌었는데 우리의 도메인이 흔들렸다

외부의 변화에 도메인이 흔들리면 왜 안될까?

우리의 애플리케이션의 핵심은 비즈니스 로직

즉, 도메인이다

우리가 해결하고자 하는 핵심

우리는 비즈니스 로직을 검증하기 위해 철저히 테스트하게 될 것이다

그런데 외부의 변화에 우리 테스트가 흔들린다

다시 한번 생각해보자

우리는 우리의 비즈니스 로직을 테스트하는 건가? 외부 연결을 테스트하는 건가?

도메인이 외부에 영향을 받는 순간 테스트는 더 이상 우리의 비즈니스를 검증하지 못한다

아키텍처의 본질

다시 한번 제목을 생각해보자

아키텍처의 본질

도메인이 외부에 영향을 받는 순간 테스트는 더 이상 우리의 비즈니스를 검증하지 못한다

검증되지 않은 비즈니스를 누가 사용하길 원할까?

어쩔 땐 되고 어쩔 땐 안되는 서비스를 나는 적어도 사용하지 않을 것이다

우리는 도메인을 지켜야 한다

그게 내가 생각하는 아키텍처의 본질이다

하지만 아키텍처는 지켜야할 도메인이 존재해야 의미가 있다

도메인을 지키려고 하다 도메인이 세상에 나오지 못하면 아키텍처가 오히려 독이 된다

그 간격을 잘 메우는 것이 우리의 역할이다