4. LAYERED ARCHITECTURE
(문제)
비즈니스 로직
UI + Database + 기타 등등 코드
- 단기적으로 가장 쉬운방법.
-도메인관련 코드를 확인 및 추론이 힘들어진다.
- UI 변경으로 업무로직이 변경, 업무로직이 변경 되면서 UI
를 변경.
- 응집력 없고 모델주도적인 객체는 구현은 어려워진다.
5. LAYERED ARCHITECTURE
(해결)
- 매우 복잡한 작업을 처리하는 소프트웨어는 관심사의 분
리가 필요 하며 , 시스템내의 상호작용은 분리와 상관없이
유지.
- 소프트웨어를 분리하는 방법으로 LAYERED
ARCHITECTURE, 좀더 구체적으로 몇개의 일반화된 계층
을 사용한다.
7. LAYERED ARCHITECTURE
(네가지 계념적 계층)
- 사용자 인터페이스(표현 계층) : 정보를 보여주고, 명령을 해석하는 일을 책임진
다.
- 응용 계층: 수행할 작업을 정의하고, 도메인 객체가 문제를 해결하게 한다. 업무
상 중요하거나 타 시스템의 응용계층과 상호작용 필요한 부분을 책임진다.
또한 이 계층은 얇게 유지된다.
-도메인 계층(모델 계층) : 업무 개념 과 정보, 규칙을 표현하는 일을 책임지며, 업
무관련 상태를 제어한다.
- 인프라 스트럭처 계층 : 상위계층을 지원하는 일반화된 기술적 기능을 제공.
메시지 전송, 도메인 영속화 및 아키텍쳐 프레임워크를 통해 네가지 계층에 대한
상호작용 패턴 지원
9. LAYERED ARCHITECTURE
(계층간 관계 설정#1)
- 각 계층은 의존성을 오직 한 방향으로 느슨하게 결합
- 상위 계층은 하위 계층의 공개 인터페이스를 호출
- 상호 작용 수단을 이용해 하위 계층의 구성요소를 직접적
으로 사용하거나 조작가능하다.
- 하위 수준의 객체가 상위 객체와 소통해야하는 경우 콜백
(callback)이나 observer 패턴을 이용한다.
- 응용계층과 도메인계층에 UI를 연결하는 패턴은 MVC에서
유래한다.
10. LAYERED ARCHITECTURE
(계층간 관계 설정#2)
- 보통 인프라스트럭처 계층은 도메인 계층 아래에 있으므
로 도메인의 대한 정보를 가져서는 안된다.
- 인프라스트럭처 기능은 대개 SERVICE로 제공 되어진다.
- 응용계층과 도메인 계층에서는 인프라스트럭처 계층에서
제공하는 SERVICE를 요청한다.
- 모든 인프라스트럭처가 상위계층에서 호출 할 수 있는
SERVICE 형태로 만들어지는것은 아니고 다른계층의 기본
적인 기능적인 기능을 직접적으로 지원하도록 제공되어지
는 아키텍쳐프레임워크도 제공한다.
11. LAYERED ARCHITECTURE
(아키텍처 프레임워크 #1)
- 인프라스트럭처가 SERVICE 형태로 제공되면 직관적 이지
만 일부 기술적인 문제는 더욱 침습적인 형태의 아키텍쳐프
레임워크가 필요하다.
- 요구사항을 통합하는 프레임워크는 다른계층이 특수한 방
식으로 구현되기를 요구
- 가장 좋은 프레임워크는 도메인 개발자가 모델을 표현 하
는데만 집중하게 해서 복합적 기술을 해결하게 한다.
- 프레임워크에서 도메인설계와 관련 의사결정을 제약하면
개발을 더디게 하는 문제가 있다.
12. LAYERED ARCHITECTURE
(아키텍처 프레임워크 #2)
- 프레임워크의 목적은 도메인 모델을 표현하고 해당 도메
인 모델을 이용해 문제를 해결하는데 있다.
- 프레임워크의 모든기능을 사용할 필요가 없다.
- 프레임워크의 유용한 기능만 분별력있게 적용 구현하면
프레임워크간 결합이 줄어 든다.
13. LAYERED ARCHITECTURE
(도메인계층은 모델이 살아가는 곳)
- LAYERED ARCHITECTURE는 다양한 계층화 계획에 사
용되지만, 도메인 주도 설계에서는 오직 한 가지 특정한 계
층이 존재 할 것을 요구한다.
- '도메인 계층'은 일련의 개념 모델과 설계요소에 직접적 으
로 관계되는 있는것을 명시한다.
- 도메인 주도 설계의 전제 조건은 도메인 구현을 격리하는
것이다.
14. LAYERED ARCHITECTURE
(결론)
- 복잡한 프로그램을 여러계층으로 나눠라
-응집력 있고 아래에 위치한 계층에만 의존하는
각계층에서 설계를 발젼 시켜라
- 상위계층과 결합을 느슨하게 유지하라
- 도메인 모델과관련된 코드는 모두 한계층으로
- 도메인 모델은 사용자 인퍼테이스 코드나 애
플맄이션 코드, 인프라스트럭쳐 코드와 격리하
라
15. SMART UI(지능형 UI) '안티 패턴'
- 수많은 프로젝트에서는 SMART UI라고 하는
훨씬 덜 복잡한 설계 접근법을 취한다.
- 도메인 주도 설계 접근법과 상호 배타적.
- 모든 업무로직을 사용자 인터페이스에 작성
16. SMART UI(지능형 UI) '안티 패턴'
(장점)
- 애플리케이션이 단순하면 생산성이 높고 효과가 즉각적.
- 능력이 부족한 개발자도 가능.
- 요구사항 분석단계에서 결함이 발생하더라도 프로토 타입
을 배포한 후에 요구에 맞게 제품을 변경해서 문제를 해결.
- 애플리케이션 서로 분리되므로 규모가 작은 모듈의 납기
일정을 비교적 정확하게 계획 할수 있다.
- 관계형 데이터베이스와 잘어울리고 데이터 수준의 통합이
가능하다.
- 4세대 언어도구와 잘어울린다.
-유지보수 프로그래머가 이해하지 못하는 부븐을 신속하게
재작업 할 수 있다.
17. SMART UI(지능형 UI) '안티 패턴'
(단점)
- 데이터베이스를 이용하는 방식 말고는 여러 애플리케이션
을 통합하기 어렵다.
- 행위의 재상용성이 없으며, 업무에대한 추상화가 이뤄지
지 않는다.
- 추상화의 부재로 리팩터링의 여지가 제한된다.
- 복잡성에 금방 압도되어 애플리케이션의 성장 경로는 부
가적인 단순 응용으로만 향한다.
