DDD와 객체지향에 대한 생각

3-layer architecture로 개발을 하다가 좋은 패키지 구조에 대한 갈증을 느껴서 시작한 DDD가 생각보다 어려운 것 같다.

현재 내 DDD 패키지구조를 살펴보면 이러하다.
interface layer의 controller는 app layer에 의존하며 service를 호출시켜 client에게 dto를 반환하거나, validation, exception을 처리하거나, session을 체킹한다.
app layer의 service는 domain layer에 의존하며 domain model class에 있는 정적 팩토리 메서드 또는 repository를 호출해 새 객체를 만들어서 crud를 수행한다.

그리고 domain layer는 그저 존재한다
언뜻보면 꽤 괜찮은 듯 하지만 aggregate root가 겨우 두개인 상황에다 이거 깔끔히 한다고 계속 고민해왔단거다..

 

DDD는 app 레이어에서 트랜잭션 관리 또는 작업 조정, 그리고 domain 로직은 domain model 내에서 캡슐화되어야 한다는 것이 기본적인 원칙이지만

어떤 개발자분은 domain이 짱이 되어야 한다며 domain service단에서 거의 모든 비즈니스 로직을 해결한다고 하시고,

또 다른 분은 domain에 아무런 메서드도 사용하지 않고 오직 app 레이어에서만 모든 걸 해결한다고 하셨다.

 

단지 개발철학일뿐 정의는 사람마다 달라서 나만의 방식대로 정리하고 상황에 맞는 파일구조를 짜는 것이 쉽지않다.

 

그렇다면 좋은 패키지 설계란 무엇일까? 를 생각해보면 간단하다. 객체지향적인 도메인 레이어를 구축하는 것이다.

결국 DDD또한 어떻게 객체지향적인 설계를 잘 할 것인가를 고민하다 선대 개발자들이 개발하게 된 구조이고, 3-layer 이든 hexagonal이든 똑같을 것이다.

 

여태 단순히 내가 쓰기에 재밌는 기술, 새로운 기술만 좇았다. 하지만 오늘 유지보수에 대한 고민을 스스로 또 튜터님과 함께 많이 해보며 깨달았다.
java 와 spring 그리고 백엔드개발의 본질은 신기술이 아니라 복잡도가 낮은 소프트웨어를 위한 코드이고, 소프트웨어의 복잡성은 도메인의 복잡성에서 이어지고 이것은 곧 탄탄한 객체지향적인 설계에서 이어진다.

그래서 이쯤에서 "객체지향" 에 대한 공부를 할 필요가 있다고 느꼈다. 

 

근데 아무래도 새로운 걸 하지 않으면 도파민이 좀 안 생겨서 질릴까봐 걱정되지만.. 튜터님과 대화하며 동기부여가 꽤 되었기 때문에 열심히 해봐야겠다. 그리고 특정 도메인을 보고 SOLID원칙을 정리해보는 숙제를 받았다. 꽤 재밌을 것 같다.