아키텍쳐란?

• 전체적인 시스템 개발에 기반을 제공하는 변경 불가한 초기 결정사항의 집합
• 다음은 아키텍쳐가 아니고 도구다.
  • 언어, 개발환경, 프레임워크, DBMS, 디자인 패턴
• 아키텍쳐는 usage(사용법)이어야 한다. 즉 사용법이 드러나야 한다.

유즈케이스란?

• 액터(시스템 사용자)가 시스템으로 무슨 기능을 하는지 나타낸다.
• 사용자가 ~하면 시스템은 ~한다.

아키텍쳐는 사용을 노출해야 한다

• 시스템을 구성한 재료(프레임워크, 언어, 디자인 패턴) 등이 아니라 시스템이 뭘하는지를 나타내야 한다.
• 유즈케이스와 UI, DB, tool 등에 대한 결정이 decouple 되어야 한다.

결정 미루기

• 좋은 아키텍쳐는 프레임워크, UI 같은 것에 대한 결정을 미뤄야만 한다라는 게 주요 목적. 처음부터 모든 걸 다 결정할 수 없기 때문
• 시간이 지날수록 결정을 위한 정보가 풍부해진다.
• MVP를 빠르게 만들고 리팩토링하거나 새로 만들어야 함

결정 미루기 예 : 파싱, 번역

• 보통 뭔가를 하려면 DB부터 생각하지만 파싱, 번역은 DB 없이도 할 수 있다.
• 유즈케이스를 구현하고
• DB에 save하는 메서드를 mock처리하거나 memory에 저장한다.
• 이만하면 DB 연동, 스키마 생성 등을 해야할 것 같은데 하지 말고 파일 시스템에 저장한다.
• 주요 아키텍쳐 결정을 연기했다. DB 대신 더 간단한 방법을 사용했다.
• 최종적으로는 DBMS를 사용한다.

중앙화된 추상화

• 많은 아키텍트는 DB를 핵심 추상화라고 생각한다. DB가 동작하고 스키마가 준비되기 전에는 어떠한 생각도 작업도 하지 않는다.
• 최종적으로 DB에 저장되어야할지라도 재료를 decouple해서 결정을 미루고 유즈케이스부터 작성한다.

결론

• 아키텍쳐를 유즈케이스에 집중하면 재료에 대한 결정을 미룰 수 있다.
• 결정 미루기는 선택권을 넓혀준다. 추후 어떤 DBMS를 사용할지 등
• 추가 요구사항이 나오면 적은 비용으로 반영할 수 있게 해준다.

출처