SOPT 하면서 궁금했던 Architecture 찾아보기
사실 처음에 SOPT를 하면서 Java, Spring, intellij 이 3박자가 모두 처음 하는 것이었기에
따라가기에 벅차서 많은걸 놓쳤다.
그러던 중 합동 세미나 전 설계하는 방식에 관해 조언을 얻던 중 교수님께서 하신 한마디....
" 이런 걸 Domain Architecture 이라고 불러요. "
???: DDD...DDD가 뭔데요?
이제서야 옮기는 알고 설계하자 DDD...!
1. Clean Architecture
우선 DDD에 대해 알아보기 전에, Clean Architecture을 언급해보고자 한다.
이유는 정말 지극히 개인적인 생각이지만
Architecture을 정리 할 수록 지금까지 화재된 Architecture이 추구하고 목표하는 것은, 비슷하다고 느꼈기 때문이다.
https://www.youtube.com/watch?v=cPH5AiqLQTo
Software Engineer Tom Hombergs가 Clean Architecture에 관해 2019년 당시 강연한 영상인데
물론...한국어 자막을 제공하지는 않지만 영어를 하실 수 있는 분들은 들어보시는걸 정말 추천합니다.
제가 사실 왜? 라는 물음으로 파고드는 편인데요
첫 시작을 Why Bother with Architecture? 이라는 주제로 Architecture에 관한 전반적인 얘기를 다루고 있습니다.
"Some people think that architecture is abount making it work "
...
"The goal of sothware architecture is to minimize the lifetime cost of software"
뒷부분은 DDD와 Hexagonal Architecture에 관해 언급하는데
결과론 적으로 Architecture이 목표하는 바는
1. Facilitating the whole develepment experience 2. minimize the lifetime cost of software
이라고 언급하고 있습니다.
구조가 왜 필요한가? 왜 이 구조를 사용하는가?
에 대한 물음으로 찾아보시는 분들은 여기서 어느정도 동의하시지 않을까 생각합니다.
2. DDD란?
DDD는 Eric Evans의 Domain-Driven Design: Tackling Complexity in the Heart of Software에서 소개된
Layered Architecture를 통해 각 layer 간 관심사를 분리하고 같은 계층, 하위 계층에만 의존해 layer간 dependency를 최소화하는 소프트웨어 접근법 입니다.
약자에서 엿볼 수 있듯이, Domain 모델을 중심으로 설계하는 방식인데
Eric Evans는 2015년 당시 conference에서 이 3가지를 언급했었습니다.
1. Focus on the core domain. 2. Explore models in a creative collaboration of domain practitioners and software practitioners. 3. Speak a ubiquitous language within an explicitly bounded context.
즉, domain에 집중하고 domain practitioners와 협업하고,
ubiquitous적인 언어로 대화하라는 것인데 처음엔 이게 무슨 소리일까 싶었습니다.
나는 분명히 구조가 궁금한것인데 언어가 왜 나오지?
2-1. Ubiquitous Language
직독하자면 보편적인 언어 라는 뜻이다.
즉, 프로젝트에 참여하는 그룹 모두가 이해할 수 있는 언어라는 뜻인데 사실 SOPT에
들어와서 팀을 꾸려 해커톤을 하기 전까지는 왜 중요한지 알 수 없었다.
"개발은 개발자가 하는데 파트끼리만 알면 되지 않나?"
지금 생각해보면 아주 그릇된 생각이다.
개발은 혼자 하는게 절대 아니였다. 다른 파트와 소통이 통했다고 생각했다가도 아닌걸 깨닳고 엎은적도 여러번 있었다.
여러가지 이유가 있겠지만 핵심은
1. 모델 기반의 언어를 사용할 것 2. 도메인 영역을 제한할것 3. Bounded context 안에서 의미를 가지고 존재할 것
그러면 또 다른 궁금증이 생긴다.
Bounded Context가 무엇일까?
위 그림을 봤을때,
Customer, Product가 겹치는 것 처럼 Account라는 단어가 어딘가에서는 계좌로, 어딘가에서는 계정이라는 뜻으로 쓰일 수 있다.
이처럼 구분되는 경계(context)를 가진 컨텍스트를 Bounded Context라고 하는 것이다
즉 어디에 속해 있는지에 따라 객체의 책임이 나뉘어지는 것인데
그렇다면 어떻게 설계하는게 좋을까?
3. DDD Architecture
https://www.nareshbhatia.dev/articles/domain-driven-design-6-layered-architecture
Domain Driven Design에서 제시하는 Layered Architecture은 위의 사진과
같은 구조로 이루어져 있다.
뜯어서 보자면
User interface Layer은 Presentation Layer이라고도 불리면서
User와 소통하는 계층의 모습으로 보입니다. 즉 Controller라고 생각할 수 있지 않을까요? 틀리면 말해주세요plz
다음의 Application Layer은 사진에 accesses domain objects라고 나와있는 것 처럼 실제 비즈니스 로직을 만드는 것이 아닌, Domain Layer에 있는
비즈니스 로직을 부른다고 생각할 수 있습니다.
Domain Layer은 그렇다면 비즈니스 로직을 작성하는 곳이겠죠?
맨 하단의 Infrastructure은 RDB와 같은 데이터베이스와 연동하여 데이터를 관리하는 Layer라고 할 수 있습니다.
즉, 응집력을 높이고 결합도는 낮춰 코드의 변경과 확장에 용이한 구조를 추구하는 것이 DDD Architecture 입니다.
다시 위 영상으로 돌아가자면 이 구조에는 한가지 문제점이 생기게 됩니다.
위에서 언급하다 싶이 Domain에서 infrastructure을 의존하기 때문에 TestCode를 작성하기가 힘들어진다는 것이죠.
저는 여기서 궁금증이 하나 더 생겼습니다.
DDD에 관해 찾아보면 Hexagonal Architecture이라는 것이 나옵니다.
DDD 자체도 완벽해 보이는데 왜 나온걸까요?
4. Hexagonal Architecture
Alistair Cockburn이 2005년 블로그에서 소개한 Architecture 입니다.
사실 Port와 Adepter이 있는 구조라서 Ports & Adapters라고 부르기도 합니다.
이 부분은
지속 가능한 소프트웨어 설계 패턴: 포트와 어댑터 아키텍처 적용하기
에서 많이 배울수 있었는데요,
사실 저는 Port를 처음 들어봐서 과연 이게 무엇인가 하는 의문이 들었습니다.
다른 정보들도 많이 찾아보니 interface를 Port로 부르는것 같았습니다.
그렇다면 이것의 등장이 어떻게 핵심이 되는걸까요?
만약 Adapter와 Use Case(사용처) 사이에 뼈대 즉, Specification만 존재하는 인터페이스를 둔다면,
외부 코드에 의해 내부의 로직이 변하는 일이 존재하지 않게 되면서
Test를 하기 좋은 환경이 만들어진다는 겁니다.
이러면 한가지 의문이 듭니다.
그렇다면 모든 패턴들 중 Hexagonal Architecture이 가장 좋은가?
이 부분을 스스로 개발도 해보고 다른 분들과 얘기했을때는,
개인적인 생각이지만 무조건 좋고 무조건 안좋은 Architecture는 없다는 생각이 들었습니다.
이부분은 다시 처음으로 돌아가서
"The goal of sothware architecture is to minimize the lifetime cost of software"
로 돌아갈 수 있지 않을까요?
그리고 이 부분이 팀의 판단의 몫이라고 생각합니다.
마치며...
아니라고 생각하는 부분이 있을 경우 말씀 부탁드립니다! 성장중인 감자입니다..!
