- 참조한 블로그 hanblueblue
- 이전에 보면 좋을 내용 PoEAA
- 추가로 공부할 수 있는 내용 해피클라우드
설계를 고려하는 이유
커다란 건축물을 만들기 위해 설계도를 그리듯이, 크고 복잡한 애플리케이션을 만들 때에도 설계가 필요합니다. 설계와 설계의 검증 없이 시스템을 만들 경우 품질이 낮고, 유지보수에 비용과 시간이 비효율 적이게 됩니다.
architecture는 애플리케이션을 구축 할 때 따라야 할 로드맵을 제공하여 체계적인 애플리케이션 완성에 도움을 줍니다. 이미 여러 architecture 패턴이 발전 하였고 가장 보편적인 Layered Architecture에 대해 알아봅니다.
레이어드 아키텍처
레이어드 아키텍처는 관심사를 4개의 레이어로 나누어 관심사가 분리(SoC)된 코드 구성을 목표로 합니다. 이러한 레이어는 추상적인 층(계단)의 개념으로 그려져, 아래의 레이어에만 접근이 가능하고, 그 반대로 상위의 레이어에는 접근 할 수 없어야합니다. 유연도에 따라 아래의 한 계층에만 접근하게 설계할 수도, 아래의 모든 계층에 접근하게 설계할 수 도 있습니다.
이렇게 층을 나누어 개발자가 특정 레이어에서 작업할 때, (AOP의 이점처럼)상위 레이어에 관심없이 작업 레이어와 그 하위 레이어에만 집중할 수 있게합니다. 각 계층은 자신에 대해 높은 응집도, 다른 계층에 대해 낮은 결합도를 갖습니다. 이는 좀 더 용이한 테스트에도 도움이 됩니다.
4개의 레이어
presentation
프레젠테이션 레이어는 ui 뷰, 템플릿, 컨트롤러, 폼을 의미합니다(흔히 말하는 MVC). 이는 외부(클라이언트, 다른 시스템)의 요청과 응답을 위한 인터페이스로, 시스템과 외부와의 상호작용하는 모든 것을 모아둔 영역입니다.
application
애플리케이션 레이어는 모든 것을 하나로 묶습니다. 서비스로 구성되기 때문에 간혹 서비스레이어로 부르는 경우도 있습니다. 이 때는 도메인 서비스와의 구별이 요구됩니다. 비즈니스 로직을 이 레이어에 구현하지 않습니다.
모든 도메인 로직은 domain layer에서 구현되고 application layer는 적절한 객체에게 도메인 로직 수행을 요청합니다. Presentation 계층에서 받은 데이터의 유효성 (Validation) 검사합니다.
애플리케이션 레이어를 usecase라는 명칭으로도 부르는데, 트랜잭션처럼 하나의 작업단위로 이해되어, 온전히 성공하거나 온전히 실패하는 결과만을 허용해야합니다(Atomicity). 비즈니스 로직과 프레젠테이션 간의 (직접적으로 통신하지 않게 하는 연결) 인터페이스라고 할 수 있습니다.
필자는 하나의 작업단위 아래 필요한 여러개의 비즈니스 로직들의 연결로 이해하고 있습니다.
domain
도메인 레이어는 시스템의 코어입니다. 모든 비즈니스 모델(로직)과 서비스를 이곳에 정의합니다. 비즈니스 로직만 담당하여 외부의 특정 기술의 구현이나 의존성을 최대한 피합니다. 도메인 객체 별로 비즈니스 로직 처리를 담당하는 레이어입니다.
애플리케이션 레이어와 나누는 이유는 새로운 비즈니스 요구에 대응할 때 기존 소스에 영향을 최소화하고, 도메인 레이어의 재활용성을 극대화 하기 위함입니다.
infrastuctrue
인프라스트럭쳐 레이어는 애플리케이션의 가장 낮은 수준의 코드를 둡니다. 데이터베이스(DAO)나 이메일, 메시징 큐 같은 (기술적인)외부 서비스와의 상호작용을 맡습니다. 여기에 포함된 코드들은 비즈니스 로직이나 애플리케이션의 작동 방식에 영향을 주지 않아야 합니다.
댓글남기기