3계층구조)

 

 

 

 

(Req.DTO) / (Res.DTO)

---

1계층 : 컨트롤러 (HTTP통신, 라우터등과 같이 통신을 담당하는 부분 ) 

---  BO(비즈니스 오브젝트)

2계층 : 서비스 (하나의 비즈니스로직)

ㄴ 하나의 비즈니스 로직을 이행하기위해서 유저정보, 결제 정보등 데이터조회가 필요하므로 

뒷단의 데이터계층에서 데이터를 조회하거나 참조하는 기능도 수행한다  

 

ㄴ트랜잭션 계층, 비즈니스 로직계층 이라고도한다 

---  엔티티 

3계층 : 레포지토리( db작업을 담당하는 부분)

ㄴ 하나의 비즈니스로직에 필요한 데이터 조회,입력,수정등을 지원하는 단계 

 

비즈니스 로직을 수행할때, 데이터 기입이나 변동이 필요할때, 이에대한 작업을 지원하고, 정보를 보관하는 계층

 

 

 

 

이렇게 3계층 구조로 나누는 이유는 뭘까?)

 

->응집도를 높이고 결합도를 낮추기 위함이다.

 

왜 그래야하지?)

 

-> 상황에따라서 소프트웨어의 일부분을 손쉽게 갈아끼울 수 있어야한다. (다른 부분에 대한 영향을 최소화한 채로!)

 

예를들면, 사용하는 DB를 바꿔야할때 개발자들을 가능한 최대한 손쉽게 레포지토리 단계에 해당하는 부분만 갈아끼울 수

 

있어야한다.  그렇지 않다면 회사 서비스에서 DB만 교체하는데에도 전체 코드를 다시 작업하는 일이 생기게 된다.

 

또 다른 예를들면, HTTP통신(단방향통신)이 아닌 TCP통신(양방향통신) 을 한다고 했을때 소프트웨어(서비스 + 레포지토

 

리)만 분리시켜서 컨트롤러 부분만 교체할 수 있는가? 이것또한 그렇지 않다면 컨트롤러(통신관련 부분) 만 교체하는데에

 

도 전체코드를 다시 처음부터 작업하는 일이 생기게된다.

 

작은 특정부분을 수정하기위해서 전체를 갈아엎어야하는 상황이 생긴다면 아주 비효율적일 것이다.

 

물론 어쩔 수 없이 계층간 의존하게 되는 부분들이 생기기 마련이다. 하지만 개발자들이 이러한 것들을 고려하지않고 개발

 

한다면, 주어진 상황이 변화했을때, 기존의 코드를 거의 대부분 지워버리고 다시 처음부터 작업해야하는 일이 많아질 것이

 

다. 그러므로 이러한 일들을 최소화하기 위해서 만들어진 전략이다.

 

 

 

 

**어플리케이션을 3개의 계층으로 분리했을때 얻을 수 있는 이점 정리)

 

1. 유연성과 확장성 : 각 계층이 독립적으로 관리, 개발할 수 있어서 시스템의 확장성과 유연성이 향상된다.

ㄴ각 계층이 독립되어있기 때문에 다른 곳에 미치는 영향없이 특정부분에 대한 확장, 수정이 용이하다. 

 

2. 보안향상: 데이터 접근에 대한 보안 강화  (데이터계층과 컨트롤러 계층이 분리되어있기 때문에)

 

3. 유지보수 용이: 특정 부분이 수정되어도 다른 부분에 미치는 영향이 적기때문이다.

 

4. 부분, 계층별로 독립적인 개발, 테스트가 가능해져서 복잡성이 줄어들고 효율성도 증가한다.