### 도메인이란?
소프트웨어로 해결하고자 하는 문제 영역을 의미
ex) 온라인 서점 : 소프트웨어로 해결하고자 하는 문제 영역
-> 이 도메인에서는 하위 도메인으로 상품조회, 구매, 결제, 배송 추적의 기능을 제공
-> 하위 도메인은 다른 하위 도메인과 연결되어 완전한 기능을 제공
-> 도메인이 제공할 모든 기능을 구현해야 하는 것은 아님 (결제와 같은 기능은 외주 가능)
즉, '도메인'은 우리가 만들고자 하는 대상이 되는 소프트웨어(문제영역)이며, 도메인 설계는 우리가 만들고자 하는 소프트웨어에 어떤 기능을 제공할지, 어떠한 데이터 구성을 가질지, 각 기능간의 관계를 어떻게 할지를 설계하는 것을 의미함.
MVC
MVC 모델은 웹 애플리케이션에서 요청과 응답을 효과적으로 처리하는 패턴
클라이언트의 요청을 Controller -> Service -> Repository -> Database의 흐름으로 처리하고,
결과를 View로 반환해 클라이언트에게 보여준다고 볼 수 있음
MVC 아키텍처
- Model
- 애플리케이션의 데이터 및 비즈니스 로직을 담당
- 데이터 베이스와 직접적으로 연결되며, Service 계층을 통해 Controller에서 데이터를 가져옴
- 데이터와 데이터가 동작하는 방식을 제공
- View
- 클라이언트에게 보여줄 화면을 담당
- HTML, JSP, Thymeleaf, React를 사용해 데이터를 표현
- 데이터의 표현 (화면에 보여줌)
- Controller
- 사용자의 요청을 받아 처리하고, 적절한 데이터를 Model에서 가져와 View로 전달
- @Controller @RestController를 사용해 구현
- 모델과 뷰의 연결고리
예를들면,
1. 사용자가 애플리케이션과 컨트롤러에 최초 처리를 요청
2. 모델에서 데이터 갱신, 생성, 삭제 조작함
3. 모델은 결과를 컨트롤러에 전달
4. 컨트롤러는 뷰에 결과를 전달하여 결과적으로는 뷰가 사용자에게 응답 보여줌
-> 사용자가 요청을 하면 모델에서 조작하고 결과를 데이터 컨트롤러에 전달. 컨트롤러는 뷰에 전달해 응답 보여줌.
책임과 의존성
유연성 있는 소프트웨어를 개발해야함. (다양한 요구사항의 변화에 대처하기 위해)
이는 책임과 의존성과 깊은 연관이 있음.
책임 : 객체가 수행해야하는 역할이나 기능을 의미
의존성 : 어떤 객체가 다른 객체에 기능을 위임하거나 사용할 때 발생
ex) class A 가 class B에 기능을 요청할 경우, A는 B에 의존하고, B는 특정 기능 수행에 대한 책임을 가짐. 좋은 설계란, 책임을 잘 나누고, 동시에 의존성을 낮추는 구조를 의미함.
그렇다면 도메인과 뷰를 왜 분리해야하는가?
-> 관심사의 분리 때문에
도메인은 무엇을 할 것인가를 담당하고,
뷰는 어떻게 보여줄 것인가를 담당.
분리를 통해 재사용, 단위 테스트의 용이성, 유지보수하기 편리, 뷰를 여러가지로 확장해도 도메인을 사용가능해 확장성, 개발 업무의 영역이 분리되어 협업의 효율이 올라간다는 장점이 있음.
뷰로 도메인이 넘어간다면?
뷰에서 핵심 도메인을 처리한다면 다양한 문제 발생 가능함.
- 로직 중복 : 뷰마다 로직을 구현하면 여러 곳에 같은 로직 반복
- 버그 발생 가능성 증가 : 로직이 뷰마다 다르게 동작할 수 있음.
- 테스트 어려움 : 로직이 UI에 묻혀있어 테스트 불가능 하거나 복잡.
- 유지보수 어려움 : 뷰가 바뀔때마다 로직 수정해야함.
도메인이 뷰를 참조하는 것은 괜찮은가?
도메인은 뷰를 몰라야 함.
-> 도메인은 순수한 소프트웨어 로직이기 때문에 어떠한 UI에서도 독립적으로 존재해야 함.
-> 도메인이 뷰를 알게되면, UI변경시 도메인에 영향 줌.
-> 도메인 로직을 재사용할 수 없고, 결합도가 높아져 유지보수 어려움.
