모델은 데이타 상태만 저장하고 있어야한다는 생각과 다르게, 모델링된 행위나 정책 그리고 데이타 매퍼까지도 모델에 포함해야 된다는 의견이 Fat Model을 좋아하는 사람들의 생각이다. 나는 이 의견에 절반정도 동의하는데,

• Controller는 View와 Model의 연결만으로 자기할일을 다 한것이다
• 정책이 모델에 있는것이 도메인의 구현 관점(정책의 구현)에서 수정이 용이하다

그럼에도 모델의 정책이 모델의 상태보다 더 빠르게 변화한다는 점, 모델이 뷰에 영향을 많이 미친다는 점 때문에 모델을 조합하고 뷰와 엮어주는 역할이 필요하다고 생각한다.

특히 MSA에서 어딘가의 Service는 내가 만드는 제품에 맞춤설계로 만들어진것이 아니기 때문에 일종의 조종(adaptation)이 필요하고 이것이 흔히 이야기하는 Service 계층이 아닐까 싶다.

일단 나의 경우에는

• 모델은 논리모델을 중심으로 설계하고 주고받는 메시지에 관심을 가지고 구현한다.
• 모델을 주고 받는 부분은 Service나 혹은 독자적인 layer에 둔다
  • 안드로이드의 Service Component와 헷갈리므로 안드로이드에서는 (나만ㅎ)모델뷰라고 한다.
  • 안드로이드의 뷰는 행동을 일으키키도하고 모델에 영향을 받기도 한다.
  • Spring이나 다른 프레임워크에서는 Service라는 이름으로 사용
• Controller는 위임의 단계를 나누는데 사용하거나 기능을 선택(dispatch) 하는데 사용한다.
  • 안드로이드에서 Controller는 뷰를 조정하는 역할로 사용하고 이를 view controller라고 한다
  • Server side에서는 (View를 포함하는) Web인지 기타 REST API인지 선택하고 Service에 위임하는 역할

이렇게 일단 정리하여 작업을 진행하고 있다.