좋은 아키텍처는 [유스케이스, 운영, 개발, 배포]를 지원해야 한다.
1) 유스케이스
- 시스템의 의도를 지원해야 한다
- 아키텍는 행위를 명확히 하고 외부로 드러내며, 이를 통해 시스템이 지닌 의도를 아키텍처 수준에서 알아볼 수 있게 만드는 것
ex) 장바구니 어플리케이션이 좋은 아키텍처를 갖춘다면, 애플리케이션은 장바구니 애플리케이션처럼 보여야 한다. 유스케이스가 구조 자체에서 한눈에 드러날 것
2) 운영
- 시스템이 단일체로 작성되어있다면 ? 추후에 멀티프로세스, 멀티쓰레드 등이 필요해질 때 개선되기 어려움.
- 아키텍처에서 각 컴포넌트를 적절히 격리하여 유지하고 컴포넌트간의 통신 방식을 특정 형태로 제한하지 않는다면, 시간이 지나 운영 요구사항이 바뀌더라도 기술 스펙트럼 사이를 전환하는 일이 훨씬 쉬워질 것이다.
3) 개발
- 아키텍처는 개발환경을 지원하는데에 핵심적인 역할을 수행
콘웨이의 법칙
시스템을 설계하는 조직이라면, 어디든지 그 조직의 의사소통 구조와 동일한 구조의 설계를 만들어 낼 것이다.
4) 배포
- 좋은 아키텍처라면 시스템이 빌드된 후 즉각 배포할 수 있도록 지원해야 함.
- 시스템을 컴포넌트 단위로 적절하게 분할하고 격리시켜야 한다.
마스터 컴포넌트는 시스템 전체를 하나로 묶고, 각 컴포넌트를 올바르게 구동하고 통합하고 관리해야 함.
5) 선택사항 열어놓기
- 좋은 아키텍처는 선택사항을 열어둠으로써, 향후 시스템에 변경이 필요할 때 어떤 방향으로든 쉽게 변경할 수 있도록 한다.
계층 결합 분리
- 단일 책임 원칙 & 공동 폐쇄 원칙 적용 ⇒ 다른 이유로 변경되는 것들은 분리, 동일한 이유로 변경되는 것은 묶는다
서로 다른 이유로 변경되는 것들?
- 서로 다른 업무 규칙들 독립적으로 변경 가능하도록
(애플리케이션 특화 업무 vs 애플리케이션 독립적인 업무 vs 데이터 베이스 등) - 유스케이스
시스템에서 서로 다른 이유로 변경되는 요소들의 결합을 분리하면, 기존 요소에 지장을 주지 않고도 새로운 유스케이스를 계속해서 추가할 수 있게 됨
개발 독립성
- 컴포넌트가 완전히 분리되면, 팀 사이의 서로 영향을 주거나 개입할 수 없음
배포 독립성
- 유스케이스와 계층 결합이 분리되면, 배포 측면에서 유연성이 생겨, 운영중인 시스템에서도 계층과 유스케이스를 교체할 수 있다.
중복 <중복이 진짜 중복인지 혹인하라.>
- 진짜 중복과 거짓 중복을 잘 판단해야 한다.
- 비슷한 화면 구조, 비슷한 알고리즘, 비슷한 데이터베이스 쿼리와 스키마를 가졌다고 중복이 아님.
- 거짓 중복으로 코드를 통합했을 때, 나중에 코드를 다시 분리할 때 수고가 많아짐. 애초에 뷰 모델을 별도로 만드는 일은 그에 비해 힘이 덜 든다.
결론
좋은 아키텍처는 시스템이 모노리틱 구조로 태어나 단일 파일로 배포되더라도, 이후에는 독립적으로 배포 가능한 단위들의 집합으로 성장하고, 또 독립적인 서비스나 마이크로서비스 수준까지 성장할 수 있도록 만들어져야 한다.
좋은 아키텍처라면 나중에 상황이 바뀌었을 때엔 다시 원래 형태인 모노리틱 구조로 되돌릴 수도 있어야 함.
좋은 아키텍처는 “결합 분리 모드(시간이 지남에 따라 바뀌기 쉬움)”를 선택사항으로 남겨두어, 배포 규모에 따라 적합한 모드를 선택할 수 있게 함.
안녕하세요 지원입니다.
대박사건