오늘은 근래에 최고의 숙면을 한 날인 것 같다. 배도 거의 나았고, 무엇보다도 정말 오랜만에 아침이 개운했다. 비록 강아지들이 울긴했지만, 내가 일어나고 나서 울었기에.. 나름(?) 괜찮았다. 그러나 피로는 많이 줄어들었지만, 내가 공부와 프로젝트에 집중을 못했다. 언제나 집중해서 할 수 있는 것은 아니니깐.. 이라 생각하며.. 오늘 공부 내용을 기록해본다.
독서: 단위테스트에 대하여
오늘은 어제 못한 단위테스트에 대한 정리를 해보았다. 나는 단위 테스트를 처음 접하게 된 것은 TDD(테스트 주도 개발) 를 공부하면서 이다.
나는 테스트 주도 개발을 처음 접하면서, 단위 테스트의 존재를 알게 됬었고, 리팩터링을 접하면서 단위테스트를 통해 리팩터링을 진행할 수 있음 을 알게되었다.
과거 내가 알고 있던 내용을 정리하면, 단위 테스트를 공부를 통해 테스트주도개발 과 리팩터링을 할 수 있을 것이라고 생각했다. 그래서 나는 첫 회사에서 가장 먼저 독서한 책의 내용이 테스트와 관련된 내용이었다.
테스트의 종류는 다양하다. 단위 테스트 외에도 통합테스트, E2E 테스트, 성능 테스트 등 많은 종류의 테스트들이 존재했지만, 나는 단위 테스트와 통합테스트, E2E 테스트에 집중했다. 다른 부분들은 내가 할 수 있는 기회가 거의 없을 것이라고 생각했고, 또한 그랬다. 그러나 지난 내가 실무에서 경험한 테스트는 E2E 테스트만 경험할 수 있었다. 팀 내 문화에서는 테스트 작성에 부정적인 인식을 갖고 있었기 때문이다.(테스트를 작성하면 개발할 시간이 없다나 뭐라나..)
단위테스트의 대상은 클래스 또는 함수이며, 통합테스트 및 E2E 의 경우, 전체 시스템 이나 기능과 같은 모듈을 테스트한다.
좀 더 자세한 내용은 개인 공부 저장소에 기록을 해두었다. 아직 단위 테스트를 설계하는 방법과 테스트 코드를 작성하는 방법에 대한 내용을 추가하지 못했지만, 내일 부지런해 추가해볼 계획이다.
https://github.com/KEEMSY/STUDY/blob/main/System-Development-Skills/UnitTest.md
독서: DDD
오늘은 개발은 안하고, 책만 본 것 같다. 어제 잘못 대답한 내용이 자꾸만 아른거려 내가 갖고 있는 DDD 관련된 책과 내가 정리했던 파일을 다시 보았다.
참고한 내용: 도메인 주도 설계로 시작하는 마이크로 서비스 개발(책), https://github.com/KEEMSY/STUDY/tree/main/Architecture/DDD
내가 정리한 내용과 책의 내용이 도메인 주도 설계에 대한 자세한 내용은 아니지만, 기본적인 내가 개념과 정리를 한 내용들이기에 다시금 복습을 했다. 오늘 집중적으로 본 내용은 전술적 설계(도메인 모델링 구성요소) 이다.
DDD의 전술적 설계(도메인 모델링 구성요소)
DDD의 전술적 설계는 도메인 모델을 구성하기 위한 패턴을 설명한다. 기존 객체 모델링 방식은 자유도가 높아, 시스템이 고도화되어 비즈니스 요구사항이 증가함에따라 여러 층의 복잡한 계층 구조로 만들게 될 가능성이 높다. 그래서 DDD의 전술적 설계를 통해 객체들의 역할에 따른 유형을 정리하고, 도메인 모델을 단순하고 이해하기 쉽게 만들어야 한다.
전술적 설계에서의 내용은 다양하지만, 그 중 나는 도메인 모델링을 위주로 공부했었고(그래서 다른 내용들은 잘 모른다..) 도메인 모델링에 해당하는 내용들을 이야기한다면 다음과 같다.
- 엔터티(Entity)
- 값 객체(Value Object)
- 애그리거트(Aggregate)
- 도메인 서비스(Domain Service)
- 도메인 이벤트(Domain Event)
이것들 중 내가 잘못 기억 및 부족하게 기억하고 있던 내용은 엔터티와 애그리거트이다.
엔터티 와 애그리거트
내가 기억하고 있는 엔터티와 애그거트에 대해 이야기해보자. 엔터티는 다른 엔터티와 구별할 수 있는 식별자를 가진 도메인 객체이다. 값 객체 와는 다르게 엔터티의 속성 및 상태는 계속 변할 수 있다.
엔터티와 값 객체를 식별하다보면, 관련된 엔터티와 값 객체가 보이게 되는데, 이 묶음을 애그리거트라고 한다. 그리고 애그리거트 내에 있는 엔터티 중 가장 대표하는(상위)의 엔터티를 애그리거트루트(AggregateRoot) 라고 한다.
엔터티와 애그리거트에 대해 내가 잘못 기억하고 있던 내용
면접에서 DDD에 대한 질문을 받았었다. 그리고 나는내 생각을 그대로 이야기 했었는데, 내가 잘못 이야기한 질문이 있다. 바로, 애그리거트루트는 어떻게 식별하나요?(애그리거트는 어떻게 묶이나요?) 이다. 이 질문의 답변이 나는 잘못됬었고, 내가 잘못 기억하고 있는 내용이 있음을 알 수 있었다.
나는 이에 대한 답을 명확하게 하지 못했다. 그저 관련된 엔터티들에서 대표할 수 있는 엔터티를 애그리거트루트라고 생각한다 답변했다.그리고 애그리거트는 어떻게 묶이나요? 에 대한 답변은 비슷한 기능을 하는 객체들 끼이가 묶인다고 답변했다.
어느정도는 맞는 답같으면서도, 개인적으로는 잘못된 답이라고 생각한다. 누구는 A엔터티가 대표한다 생각하며, 또다른 누구는 B엔터티가 대표한다 생각할 수 있다. 또 나는 이것들이 비슷하다고 생각하는데? 하지만 다른사람은 비슷하지 않다 이야기 할 수 있다. 즉 내 답변은 명확하지 않으며, 논쟁의 여지가 분명하다.
그렇다면 어떻게 이야기했어야할까? 내가 다시 복습하면서 생각한 정답은 다음과 같다.
- 애그리거트가 묶이는 단위는 트랜잭션이다. 트랜잭션을 하는데 다른 서비스의 엔터티를 참조해야한다면, 애그리거트가 잘못 묶인 것이다. 애그리거트 내에서 발생한 트랜잭션은 해당 애그리거트 내에서 이뤄져야한다.
- 애그리거트루트는 도메인 전문가들과 협의 후에 정해진 엔터티들 중 가장 상위의 엔터티를 애그리거트루트 로 지정한다.
사실 애그리거트루트에 대한 정의는 이전과는 크게 다른게 없다. 하지만 부가적인 설명이 추가된다. 도메인 전문가들과 협의 후에 정해진 엔터티들 중 이어야한다는 것이다. 다소 여전히 애매하게 보일 수 있지만, 이 차이는 크다고 생각이 든다. 각 도메인의 전문가와 함께 식별해내는 것이라면, 서로의 의견차이가 근거가 있을 것이고, 그로 인해 어느 한쪽으로 설득이 되지 않을까 싶다.
벌써 내일이면 일주일의 중반 수요일이다. 왜 벌써 수요일인지 모르겠다. 그리고 오늘 하루가 왜 벌써 끝난지는 더 모르겠고.. 피로도 줄어들고, 컨디션도 회복되고있으니, 다시 정신 바짝 차리고, 재정비해서 앞으로 다시 나아가야겠다!!
프로젝트하자 성연아!
독서하고 정리 잘하자 성연아!!
복습도 잊지말자 성연아!!!
'회고 > TIL' 카테고리의 다른 글
| 최종 불합격, 독서: 예외처리, 개발 안티패턴에 대하여 (1) | 2023.10.19 |
|---|---|
| 논블록킹 I/O 에 관하여, 단위 테스트를 설계하는 방법 (0) | 2023.10.18 |
| 장염, 독서: 리팩터링과 단위 테스트 , 인터뷰 회고 (0) | 2023.10.16 |
| 3시간의 짧고 재밌었던, 최종 인터뷰 후기 (0) | 2023.10.13 |
| 기술 인터뷰 후기 (0) | 2023.10.06 |
