가장 기본적인 clean architecture에 대한 정의와 구성요소들, terms에 대해 정리하였고 다음은 객체지향프로그래밍과 함께 의존성 규칙에 대한 내용과 더 심화된 내용을 정리해보겠다
SITUATION !
어떤 복잡한 기능이나 요구사항을 구현해야하는 상황이 주어졌을 때,
: 설계를 잘 하고 들어가야 한다!
왜?
소프트웨어의 본질은 변하는 것이기 때문!
소프트웨어의 요구시항은 시시각각으로 변한다.
새로운 기능을 개발해야 할수도 있고, 심지어 이미 있는 기능을 바꿔야 할수도 있다.
소프트웨어가 현재의 요구사항을 정확히 만족하도록 개발하는 것도 중요하지만, 이 보다 더 중요한 소프트웨어 개발자의 사명은 소프트웨어가 쉽게 변화할 수 있도록 만드는 것,
소프트웨어의 구조를 적절히 설계해야 한다.
적절히 코드를 나누고, 적절한 위치에 적절한 책임을 두고, 나뉘어진 코드끼리 적절한 의존성을 가지게 하는 행위가 포함된다.
소프트웨어가 쉽게 변화할 수 있기 위해서는 어떻게 해야하나?
- 바꾸어야 할 부분을 쉽고 명확하게 파악할 수 있어야 하고
- 변경이 최소한으로 일어나야 한다
Architecture
: overall design of the project
classes나 files 또는 컴포넌트, 모듈에 들어가는 코드의 조직, 구조
그리고 이것들이 어떻게 서로 그룹지어 연관되는지 아는것이 아키텍쳐의 핵심이다.
아키텍쳐는 어플리케이션이 어디서 그것의 핵심 기능을 실행시키는지, 그 기능들이 어떻게 user interface와 database와 연관되는지 정의해준다.
그래서, 클린 아키텍쳐는 프로젝트가 조직화되는 것을 참고하며, 프로젝트가 변화함에 따라 쉽게 변화하는 것을 알 수 있다. 이건 단순히 발생하는 것이 아니라, 의도된 계획이고 필연적인 것이다.
Clean Architecture
프로젝트를 만들어가는 핵심 중 하나 : easy to maintain!
유지를 쉽게 하지 위해서는 어떻게 해야하나?
컴포넌트 사이에 클래스나 파일을 분리하는 것,
다른 컴포넌트들 사이에서 독립적으로 변화할 수 있도록 하기위함이다.
Domain
안쪽의 원은 어플리케이션의 도메인 레이어이다. 이곳은 비즈니스 로직이 들어가는 곳이다. 단순히 원론적인 비즈니스 뜻을 생각하는 것뿐만이 아닌, 어플리케이션이 무엇을 하는지에 대한 핵심, 그리고 코드의 핵심 기능이다.
예를 들어, 번역앱은 번역을 하는 것, 그것이 핵심이다. 따라서 이러한 비즈니스 룰은 앱의 핵심 가치를 자주 변화시키지 않기 때문에 꽤나 안정적이다.
Infrastructure
바깥의 원은 어플리케이션의 인프라이다. 이것은 UI나 데이터베이스, web APIs, frameworks와 같은 것이다. 따라서 도메인보다 더 쉽게 변한다.
도메인과 인프라의 사이의 경계가 생성되기 때문에, 도메인은 인프라에 대해 아는 것이 없다.
그 뜻은, UI와 데이터베이스는 비즈니스 로직에 의존하지만, 비즈니스 로직은 UI나 데이터베이스에 의존하지 않는다.
이 사실은 이것을 plugin architecture로 만든다. UI가 web interface든, a desktop app이든 mobile app이든 상관 없다는 뜻이다. 또한 데이터가 SQL에 저장되든 noSQL에 저장되든 클라우드에 저장되는 상관 없다는 뜻이다. 도메인은 상관하지 않으며, 단지 인프라만 쉽게 변화시킬 뿐이다.
도메인과 인프라로 크게 클린 아키텍쳐의 개념에 대해 나누어 봤다면 더욱 디테일하게 용어들을 정리해보자
