모놀리식 애플리케이션이란?

• 모놀리식 애플리케이션은 그 동작에 있어서 완전히 독립적인 애플리케이션
• 동작의 핵심은 자체 프로세스 내에서 실행되고 전체 애플리케이션은 일반적으로 하나의 단위로 배포
• 애플리케이션을 수평으로 확장해야 하는 경우 일반적으로 전체 애플리케이션이 여러 서버 또는 가상 머신에서 중복됨

레이어란 무엇입니까?

전체 애플리케이션의 하나의 단위로 묶이다 보니 그 안에서 기능이 추가될 때마다 복잡성이 증가한다. 이를 해결하기 위해 책임이나 문제에 따라 애플리케이션을 나누어준다. 이는 문제 분리 원칙을 따르며, 개발자가 특정 기능이 어디에 구현되는지 쉽게 찾을 수 있도록 증가하는 코드베이스를 정리하는 데 도움이 된다. 이런 코드 구성적인 장점 이외의 장점도 존재한다.

레이어드 아키텍처 장점

• 공통 기능을 전체 애플리케이션에서 재사용 가능
  • 여러 레이어로 구성하면 공통 하위 수준 기능을 애플리케이션 전체에서 재사용 가능
  • 코드의 양이 줄어들고 애플리케이션에서 DRY(반복 금지) 원칙에 따라 단일 구현을 표준화 할 수 있음
• 캡슐화적 특성
  • 애플리케이션에서 다른 레이어와 통신할 수 있는 레이어를 제한
  • 레이어의 종속 관계에 따른 코드 변경시 애플리케이션에 대한 영향력이 낮음
    • 한 레이어가 변경되거나 대체되면 해당 레이어와 함께 작동하는 레이어만 영향을 받음
    • 어떤 레이어가 어떤 레이어에 종속되는지를 제한하면 단일 변경 내용이 전체 애플리케이션에 영향을 미치지 않도록 변경의 영향을 줄일 수 있음
  • 애플리케이션 내에서 간단하게 기능을 대체 가능
    • 향후 요구 사항의 변화에 따라 구현을 교환할 가능성 외에도, 애플리케이션 레이어를 사용하면 테스트 목적으로 구현을 쉽게 교환 가능

구조

• User Interface (Presentation Layer)
  • 사용자는 UI를 통해 요청을 생성
  • UI는 Business Logic과만 상호작용
• Business Logic (Business Layer)
  • 애플리케이션이 어떻게 작동해야 하는지에 대한 핵심 행동(core behavior)
  • 고객의 요구가 변경될 때마다 바뀔 수 있음
  • Data Access Layer와
• Data Access (Persistence Layer)
  • 데이터에 직접적으로 접근
• Database Layer (추가 ++)
  • 실제 데이터 베이스 자체를 말함

Spring에서의 Layer

Layer	Spring
Presentation Layer	View와 Controller
Business Layer	Service
Persistence Layer	DAO
Database Layer	DB

• Presentation
  • 브라우저상의 웹 클라이언트의 요청 및 응답을 처리
  • 서비스계층, 데이터 엑세스 계층에서 발생하는 Exception을 처리
  • @Controller 어노테이션을 사용하여 작성된 Controller 클래스가 이 계층에 속함
• Service
  • 애플리케이션 비즈니스 로직 처리와 비즈니스와 관련된 도메인 모델의 적합성 검증
  • 트랜잭션 관리
  • 프레젠테이션 계층과 데이터 엑세스 계층 사이를 연결하는 역할로서 두 계층이 직접적으로 통신하지 않게 함
  • Service 인터페이스와 @Service 어노테이션을 사용하여 작성된 Service 구현 클래스가 이 계층에 속함
• Data Access
  • ORM (Mybatis, Hibernate)를 주로 사용하는 계층
  • DAO 인터페이스와 @Repository 어노테이션을 사용하여 작성된 DAO 구현 클래스가 이 계층에 속함
  • Dabase에 data를 CRUD(Create, Read, Update, Drop)하는 계층

DDD (Domain Driven Developement)

도메인 패턴을 중심으로 놓고 설계하는 방식이다.
(DDD 자체를 이해하지 못했으므로 간단하게 짚고 넘어가기만 한다.)

개발 진행 중 기획, 설계, 개발 단계가 나뉘면서 처음 생각했던 것과 결과물이 다르게 나오는 경우가 많았다. 이를 해결하기이해 같이 도메인을 중심으로 설계해 문제를 줄인다.

• 도메인 그 자체와 도메인 로직에 초점을 맞춘다는 것

  • 일반적으로 많이 사용하는 데이터중심의 접근법을 탈피해서 순수한 도메인의 모델과 로직에 집중하는 것을 말한다.

• 보편적인 언어의 사용

  • 도메인 전문가와 소프트웨어 개발자 간의 커뮤니케이션 문제를 없애고 상호가 이해할 수 있도록 하는 과정
  • 모든 문서와 코드에 이르기까지 동일한 표현과 단어로 구성된 단일화된 언어체계를 구축해나가는 과정
  • 분석 작업과 설계 그리고 구현에 이르기까지 통일된 방식 소통이 가능해진다.

• DDD의 핵심원리

  • 소프트웨어 엔티티와 도메인 컨셉트를 가능한 가장 가까이 일치시키는 것
  • 분석모델과 설계가 다르고 그것과 코드가 다른 구조가 아니라 도메인 모델부터 코드까지 항상 함께 움직이는 구조의 모델을 지향하는 것

Domain 이란?

소프트웨어가 해결해야되는 문제, 어떤 활동이나 관심과 관계가 있는 지식을 말한다.
도메인의 한 부분에 Business Logic이 포함된다.

ex) 쇼핑몰 사이트를 구축한다고 했을 때 로그인을 해서 상품을 비교하고 주문을 하는 전체 과정이 도메인이 될 수 있다.

스프링에서 Domain이 일종의 Model로 아래와 같은 의미로도 사용된다. DDD의 도메인과의 구분을 잘 해주어야 한다.

• DB의 테이블과 매칭될 클래스
• Entity 클래스라고도 부른다.

DDD Layer

Layer	설명
사용자 인터페이스(UI),표현(Presentation)	요청을 처리하고 사용자에게 정보를 보여준다.(Controller)
응용(Application)	요청한 기능을 도메인 계층을 조합해서 기능을 실행한다. 업무 로직은 도메인 계층에서 구현한다. (Service)
도메인	시스템에 제공할 도메인 규칙을 구현한다. (Aggregate, Entity)
인프라스트럭쳐(Infrastructure)	데이터베이스나 메세징 시스템 같은 외부시스템과 연동한다. (JPA, Message Queue, External API)

In Spring

기존의 계층 아키텍처에서 Business Layer에 해당되었던 Service 부분을 다시 Application(Service)와 Domain으로 나눈 것으로 볼 수 있다.

• Service
  • 서비스 부분에는 핵심 기능에 해당되는 Business Logic이 없다.
  • 공통적인 기능, 부가적인 기능들이 이 영역에 해당된다.
• Domain
  • Business Logic이 도메인 영역에 위치한다.

아직 잘 모르겠다.

레이어 아키텍처를 공부하면서 추가적으로 나온 클린 레이어 아키텍처랑도 비슷한 부분이 있는거 같다.