2020년 기출문제 - 소공 정리(디자인패턴 다시 공부)

 

Agenda

1. 클린 아키텍처

2. 기능점수 산정법

3. 디자인 패턴

---

클린아키텍쳐

https://www.youtube.com/watch?v=Ql7CoQminoM

 

 

- 레이어드 아키텍쳐의 문제점

: 위의 그럼 처럼 각 레이어에서 처리 요청이 되면, 각 계층간 의존 관계가 형성이 됨(의존성) 따라서, 하위 레이어의 변화에 따라, 상위 레이어가 변하게 되는 문제점이 발생함

따라서, 한 계층의 수정이 전체 시스템의 수정하는 문제가 발생함

- 코드 변경이 어려움

- 테스트도 쉽지 않음

- 의존성 때문에, 1 개발의 변화로 프로젝트 전체가 변경이 발생 할 수 있음

 

===> 이를 위한 해결책으로, Presentation layer의 변경이, 타 layer에 영향을 안준다면, 문제가 해결 될까?

 

-클린 아키텍처

위의 레이어드 아키에서 발생하는 문제를 해결하기 위해 presentation layer (DB 변경) 의 변경에 의존하는 것이 아닌, 도메인에 의존 하는 방법으로 레이어드 아키텍처의 문제점을 해결함

 

클린 아키텍처도 의존성의 방향이 entity로 들어가는 방향은 레이어드 아키텍처와 동일 함.

 

 

(1, 2번은 장점, 3번은 단점임)

클린아키텍처 크게는 2가지 계층

1) usecase , Entity 계층 : 외부 요소에 대해 절대로 알면 안됨

2) 외부 요소를 사용하는 계층

---

클린 아키텍처 4가지 레이어

1) entity 레이어 : 핵심적인 entity나 도메인 객체를 나타냄, 비즈니스 로직이나 규칙을 나타냄, 외부 요인에 영향이 없음

2) use case 레이어 : 특정 비즈니스 로직을 포함하여, 데이터 저장/Ui 등에 관심이 없다

3) Adapter 레이어 : 데이터를 application에서 사용하는 형태로 변환, 내부에서 사용하는 데이타를 외부 형태로 변환

4) infrastructure 레이어 : 특정 framework 과 기술에 의존

 

이렇게 하면, 각 레이어별로 상당히 모호함 => 그러나, 어떻게 하라는 지침이 존재하지 않음

---

이를 위한 reference로

헥사고날 아키텍처는 클린 아키텍처 특징과 유사하다 - 클린 아키의 적용 ref 및 사례가 적기 때문에, 보완한 것임

의존 관계를 개선한다고 해서, 항상 좋은 것은 아니다, 레이어드 아키에 비해서, 소스코드가 중가하고 복잡도가 증가 할 수 있다는 단점이 있음

 

그럼 언제 적용해 보는 것이 좋은가?

 

---

기능점수 산정법

DET : (Data element type) 데이타 요소 유형 - 고유하며, 사용자가 식별 가능한 비반복 필드

RET : (Record element type) 레코드 요소 유형 - 서브 그룹없이 학생 table 자체 1개임

- 짧은 영상 (이해 용이)

https://www.youtube.com/watch?v=n4KgToeGUvM

 

- 기능 점수 계산법 : 바이블 같은거네, 한국 소프트웨어 산업협회에서 만든 교육 자료

https://www.youtube.com/watch?v=_phEH6ubtDI&list=PLvCgLYmQugxgqBuzCLGLbDpL9TsZ1IcO9&index=1

 

---

3. 디자인 패턴

전체 내용 잘 정리됨- 시간을 갖고 꾸준히 공부하기

https://www.youtube.com/watch?v=An7kqZ5D7j8&list=PLe6NQuuFBu7FhPfxkjDd2cWnTy2y_w_jZ