계층화 아키텍처

마지막: 도메인 격리 1



본질적인 원칙은 레이어의 모든 요소가 동일한 레이어의 다른 요소 또는 그 "아래에있는"레이어의 요소에만 의존합니다 (2 부 4 장부터).

각각의 층이 특정 측면을 전문적으로 다루면 응집도가 높아지고 해석하기 쉽습니다. 게다가, 각 레이어는 별도의 속도로 진화하기 때문에, 분리하는 것으로 보수에 걸리는 비용이 낮아집니다.

각 레이어의 요소는 각각 다음과 같은 책임이 있습니다.

사용자 인터페이스 (프레젠테이션)

사용자에게 정보 표시 · 사용자 명령 해석

다른 컴퓨터에 정보를 제공하고 다른 컴퓨터의 명령을 해석

MVC 아키텍처에서 말하면 C

신청

할 작업을 조정 ○○하고, △△하고, xx한다. 실제 처리는 도메인 계층에 의해 수행됩니다

얇게 유지 (메소드는 몇 줄로 끝난다)

상태 없음

사용자 및 프로그램이 수행하는 작업의 진행 상황을 반영하는 상태가 있습니다.

책의 은행 계좌 이체 예에서 말하면,
1. 트랜잭션 시작 (실제 처리는 인프라가 수행 beginTransaction())
2. 계좌이체를 실시한다(실제의 처리는 계좌모델이 실시하는 transfer())
3. 확인(실제의 처리는 계좌 모델이 실시하는 confirm())
4. 등록(실제의 처리는 인프라가 실시하는 commit())

4행의 메소드가 된다

도메인 (모델)

비즈니스 개념, 정보, 비즈니스 규칙

비즈니스 소프트웨어의 핵심

인프라

일반적인 기술적 기능

메시지 보내기

지속성

위젯 그리기

특히 모델을 분리하는 것이 중요한 것은 지난번 읽은 대로입니다.

의외로 어려운

응집도가 높은 측면을 격리하는 레이어를 선택하는 것은

경험과 관습에 의한 어떠한 수렴이 보인다. (제2부 제4장부터)

자신도 그랬습니다만, 처음에는 특히, 어플리케이션층에 모델에 써야 할 비즈니스 룰을 써 버리는 경우가 많습니다.
이것은 경험과 익숙성이 필요하네요.

응용 프로그램 계층을 작성할 때 if 또는 for를 작성할 때 조금 멈추고 "이것은 모델에 작성해야합니까?"라고 생각하는 버릇을 붙이면 좋을 수 있습니다.

조금 기다렸다.

모델을 격리한다는 것을 몇번이나 주장하고 있습니다만, 최초의 그림을 봐 주시는 것을 알 수 있다고 생각합니다. 사실 모델은 인프라 계층의 요소를 가지고 있습니다. 완전히 분리되지 않았습니다.

모델을 완전히 격리하는 것이 중요하지만, 그 궁리에 대해서는 또 후일. . .