# SW Architecture와 SW Design Pattern의 개념은 어디서부터 출발했을까요?
## 두 개념은 왜 필요할까요?
- 동일한 기능을 하는 두 프로그램이 있다면 짜임새 있는 프로그램이 상관이 없지만 이후에 기능을 추가한다거나 유지보수가 필요한 프로그램이라면 좋은 구조로 짜인 프로그램이 시간과 비용이 훨씬 더 적게 들기 때문에 SW 아키텍처와 디자인패턴을 잘 사용해서 작성하는것이 필요하다.

## 두 개념의 차이점은 무엇일까요?
- 아키텍처는 서브시스템, 컴포넌트, 모듈의 관계를 관리하는 역할
- 디자인패턴은 아키텍처보다 좀 더 작은 분류의 문제를 해결하기 위한 노하우 모음집
# 애플이 이야기하는 MVC 구조는 (무엇)을 구분짓는 용도이며 (왜) 그것을 구분지을 필요가 있을까요?
- 역할을 구분짓는 용도?
- Model : 데이터 캡슐화, 조작, 처리. 데이터 관리
- View : 사용자가 보이는 화면. 인터페이스 표시. 모델의 데이터를 표시해주고, 데이터 편집할 수 있도록 함
- Controller : 뷰와 모델사이 중개자 역할. 어플리케이션 설정, 수명주기 관리
- 역할이 분리되어 있어서 유지보수가 쉽다
- MVC패턴을 가진 프로그램은 그렇지 않은 프로그램 보다 더 쉽게 확장할 수 있다
- 뷰와 모델의 의존성을 없애기 위함이다. 이렇게 되면 뷰와 모델의 결합도가 낮아지며 재사용성이 증가한다.

## 어디서 등장했을까?
- sw 아키텍처의 등장
- 소프트웨어 아키텍처는 1968년 Edsger Dijkstra 와 1970년대 초 David Parnas 의 연구에 그 기원을 두고 있습니다.
- 소프트웨어 시스템의 구조가 중요하고 구조를 올바르게 잡는것을 중요하다고 생각함. 근본적인 측면을 정의하고 체계화 하려는 노력이 있었음.

- 디자인 패턴의 등장
- GOF의 책

앨런케이가 창시한 객체 지향 프로그래밍은 다음과 같은 고민에서 시작 되었다.

> 좋은 코드를 만들기 위해서,
>
>
> 어떤 방식으로 코드를 나누고 묶어줘야 할까?
>
> 어떤 방식으로 코드를 추상화해야할까?
>

여기에 대한 답은 **'객체'라는 단위들이 '메시지'를 주고받는 형태로 소프트웨어를 추상화하자**는 것이었다.

트라이브는 여기서 한 발 더 나아간다.

트라이브가 GUI를 사용하는 애플리케이션을 잘 보니, 'UI 관련된 코드'와 '데이터 저장/처리 코드'는 특성과 하는 일이 뚜렷하게 달랐다. 변경하는 이유나 시점도 무척 달랐다.

트라이브는 **'비즈니스 로직'** 과 **'시각적인 UI'** **둘 사이를 연결해주는 부분**을 코드 안에서 분리하고 역할 부여를 해줘야 한다는 생각을 하게 된다.

## 아키텍처와 디자인 패턴은 왜 필요할까?

주어진 상황에서 소프트웨어 아키텍쳐에서 일반적으로 발생하는 문제점들에 대해 일반화 되고 재사용 가능한 솔루션들이 아키텍처와 디자인 패턴이다. 아키텍처는 디자인 패턴과 유사하지만 더 큰 범주에 속한다.

즉, 개발자들이 소프트웨어 개발을 하며 마주한 문제들의 솔루션을 정리해 놓은 것이 아키텍처와 패턴이다.

우리는 이러한 솔루션을 이용한다면 프로젝트에 대한 개발 언어, 구조 및 패턴, 역할 담당 등 다양하게 세분화 될 것이다. 이 과정은 물론 혼자 프로젝트를 진행할 때보다 더욱 복잡해질 것이지만 프로젝트의 성과와 프로젝트 질은 올라갈 것이다.

- 복잡한 구조 단순화
- 해결 방안 도출
- 효율적인 코드 작성

아키텍처를 고민했을 때(파란선)과 그러지 않았을 때(노란선)