해결된 질문
작성
·
2.2K
1
안녕하세요. 영한님.
복슴겸 해서 강의를 다시보다 궁금한 점이 있어 질문드립니다.
강의에서
member 패키지에 MemoryRepository 인터페이스를 작성하셨고 해당 인터페이스의 구현체는 다른 패키지에 작성하는게 좋다고 말씀하셨는데요,
실제 개발하실 때 어떠한 패키지명으로 구조화 하시는지 알 수 있을까요?
hello.core.member에 인터페이스와 구현체 코드가 다 들어가 있는데 어떻게 패키지를 세분화 하시는지 궁금하네요!
사실 별거 아닌 간단한 질문일 수 있는데, MVC 강좌 진행 사항을 여쭙기 위한 build-up입니다.ㅎㅎㅎ
MVC 강의 기대됩니다 😎
답변 1
6
안녕하세요. OMG님^^
도메인 주도 설계에서는 이론적으로 다음과 같이 나누는 것을 이야기합니다.
- hello.web
- hello.domain
- hello.infrastructure
Domain에 Repository의 인터페이스를 두고, 그 구현은 infrastructure라는 전혀 다른 패키지에 두는 것이지요.
관련해서 다음 링크를 보시면 자세한 이해가 되실거에요.
이렇게 구현을 완전히 다른 패키지에 두면 확실히 구현체를 변경할 때는 장점이 있습니다. 예를 들어서 구현을 JDBC에서 JPA로 변경하거나, 쉽지는 않지만, DB 자체를 RDB에서 NoSQL로 변경하거나 할 때 Domain 영역을 최대한 유지하면서 구현을 변경할 수 있지요.
그런데 구현 클래스의 패키지가 너무 멀어지게되면 막상 코딩할 때, 실무 개발자 입장에서는 생각을 한번 더 해야합니다. 그리고 스프링 데이터 JPA를 사용하면, 이미 너무 많은 기능이 제공되기 때문에, 이렇게 까지 해야하나 고민이 됩니다.
그래서 이론적으로는 이렇게 별도의 infrastructure를 두는 것이 좋지만, 실용적인 관점에서 데이터 접근 기술 자체를 변경할 일이 없다고 생각이 되면, domain안에 임의의 패키지를 만들어 사용하거나, 그냥 같은 패키지에 구현체를 만들어서 사용합니다.
저는 실용적인 관점에서 domain안에 같은 패키지를 사용하다가 만약 정말 데이터 접근 기술을 분리해야 할 것 같으면 그때 한번 리팩토링 하는 것을 선호합니다.
추가로 방금 말씀드린 맥락은 다음 글을 보시면 도움이 되실거에요.
https://www.inflearn.com/questions/16046
패키지 이름은 그때그때 달라서 딱 뭐라고 정의하기가 애매하네요. 최대한 단순하고, 이해하기 쉬운 방법을 고민하고 선택한다는 정도로 말씀드리겠습니다.
그럼 빌드업은 끝났으니 ㅎㅎ MVC 강좌 소식을 전해드릴게요.
MVC 강좌는 순수한 서블릿으로 시작해서 스프링 없이 작은 MVC 프레임워크를 만들어보는 과정으로 시작할 예정입니다. 쉽게 이야기해서 작은 스프링 MVC를 직접 만드는 과정을 통해 자연스럽게 실제 스프링 MVC가 어떻게 동작하는지 이해하게 되는 것이지요. 그리고 예제를 통해 스프링 MVC 전반의 기능을 알아보고, 실제 동작하는 페이지들도 만들어볼 예정입니다.
스프링 MVC가 원래 방대한데, 이론과 활용을 단계별로 나누어 설명을 하다보니 강의 분량이 생각보다 많이 길어졌고, 결국 강의 준비 시간도 많이 걸리네요. 그래서 오픈일자를 앞당기기 위해 강의는 2강으로 나누어 출시할 예정입니다.
1부는 2월말 ~ 3월초가 현재 유력합니다. ㅎㅎ (제발...)
2부는 3월말~ 4월초 예정입니다.
감사합니다!