계층분리의 필요성

예를들어 ui담당하는 코드에서 비즈니스로직, 디비접근로직 다 넣어버리면 어떻게될까?
동작이야 하겠지만 이 부분을 웹으로 바꾸려고 한다면 대대적인 수정작업이 필요할것이다. 각 로직을 service, repository로 나눠야하고.. 또 뭐가있지?

(1) 관심 범위 축소 (관심사 분리)
(2) 모듈 교체의 용이성
(3) 좀 더 용이한 테스트

관심범위 축소

예를들어 controller(presentation 계층)에서 service(domain, business계층)에도 접근하고, repository(data access계층)에도 접근한다고 가정하자 그러면 repository의 변화가 service에도 영향을 미치고 controller에도 영향을 미치게된다
만약에 controller는 service에만 접근하게 된다면 controller에서는 한단계더 건너뛴 repository의 변화는 신경쓰지 않아도된다. 생각의 범위를 좁힐 수 있다. 개발을 하다보면 controller를 작업하다가 repository를 작업할수도 있는데 이때 쉽게 작업의 전환을 가능하게 해준다. controller에서 repo도 참조하게된다면 repo의 변화를 신경써 가면서 작업을 해야하기때문이다.

모듈교체의 용이성

예를들어 디비관련된 무언가를 교체해야할때 교체해야할부분이 repository만으로 축소된다.

용이한 테스트

이부분은 이해를 못하겠어서 일단넘겼다.
testdouble은 ui에 모든 로직이 다 몰려있어도 할 수 있지 않을까..?

도메인 계층
도메인 해결에 순수하게 집중하는 계층
Business 로직만 담당하며, 외부의 특정 기술이나 구현 의존성을 최대한 피한다.
서비스 계층
기반 서비스 계층 혹은 애플리케이션 계층 등으로 불린다.
도메인 로직과 함께 사용되는 기반 환경의 로직들을 수행한다.
트랜잭션
메일 & SMS 발송 등 다른 인프라와의 통신을 담당하는 역할도 한다.

도메인과 모델의 차이

• 화면에서 보일때만 사용하면 model이고 db와 매핑된 클래스인경우는 domain