🟥Layerd Architecture

https://velog.io/@gmtmoney2357/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%EB%A0%88%EC%9D%B4%EC%96%B4%EB%93%9C-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98Layered-archi

레이어 분리

1. 일반적으로 4계층으로 레이어를 구분한다. 프레젠테이션,비지니스,퍼시스턴스,데이터베이스 레이어 로 나눈다.

2. 각 레이어는 애플리케이션에서 레이어 별로 책임져야할 부분을 책임지고 수행한다.

관심사 분리

1. 중요한 특징은 관심사의 분리이다. ( SoC )

2. 비지니스 레이어는 데이터를 어떻게 받아야하며, 어떻게 보여줄지 관여 할 필요가 없다.

3. 따라서 기술적 부분에 집중할 수 있지만 , 변화에 반응하는 능력(민첩성)은 떨어진다는 단점이있다.

도메인 변경의 어려움

1. 도메인 분할 이키텍처와 반대로 기술 역할에 따라 묶는다.

2. 즉, 어떤 도메인은 모든 레이어에 분산되게 된다. 그래서 이 도메인을 변경하는 것은 쉽지 않다.

3. 예를 들어 고객 도메인을 변경하려면 모든 레이어에 관련된 내용을 모두 변경해야한다.

4. 이런 이유로 레이어드 아키텍처 스타일은 DDD( 도메인 주도 설계 ) 방식과는 상반된다.

싱크홀 안티패턴

1. 요청이 한 레이어에서 다른 레이어로 이동 할 때 각 레이어가 아무 비지니스 로직도 처리하지 않고 그냥 통과하는 것을 말한다.

2. 이러한 흐름은 불 필요한 객체 초기화 및 처리를 빈번하게 유발시켜 쓸데 없는 메모리를 소모하여 성능에도 부정적인 영향을 준다.

3. 물론 싱크홀 안티패턴이 없을 순 없다. 전체 요청의 20%가 싱크홀인 정도면 그런대로 괜찮은 수준이다.

4. Controller에서 흔히 곧바로 Service 로직으로 처리를 맡겨버리는데 이에 해당하는 것인가? Validation 체크나 Http Methods를 검증하는 것 만으로도 제 역할을 하고 있는 것 인가?

어디에 쓰는게 좋은가?

1. 작고 단순한 앱이나 웹사이트에 알맞는 아키텍처이다. 특히 처음 구축을 할 때, 출발점으로 괜찮다

2. 그리 복잡하지 않으며 어쩌면 비용도 가장 저렴한 아키텍처 스타일이므로 소규모 어플리케이션에 적합하다.

3. 규모가 커질수록 유지 보수성 , 민첩성 , 시험성, 배포성 같은 특성이 점점 나빠진다.