좋은 아키텍처가 지원하는 것들 유스케이스 운영 개발 배포 유스케이스 시스템 아키텍처는 반드시 시스템의 요구사항을 지원해야 한다. 명확한 이름을 짓는 것, 유스케이스 단위로 분리하는 것이 유스케이스를 지원하는 좋은 방법이 될 수 있다. 운영 운영시에 어떠한 환경이 필요한지에 대해 고민하다 보면 시스템마다 다른 아키텍처를 가져가게 된다. 어떤 시스템은 실시간 처리를 해야할 수도 있고, 어떤 시스템은 대용량의 데이터를 다루어야 할 수도 있다. 그리고 또 어떤 시스템은 트래픽이 많지 않아 단순한 요청만 처리하는 시스템일 수 있다. 각각의 특징마다 어떤 시스템은 마이크로 서비스로, 어떤 시스템은 모노리틱 구조로 구현하면 된다. 만약 모노리틱 구조로 시스템 아키텍처를 구현하더라도 소스 코드 단계에서 컴포넌트로 잘 ..
CleanArchitecture
아키텍트는 프로그래밍 작업을 놓아서는 안된다. 아키텍트는 프로그래밍 작업을 통해 발생하는 문제를 경험하고 프로그래머를 지원하는 역할을 해야 한다. 시스템 아키텍처의 목표는 시스템을 쉽게 개발하고 배포하고 운영하며 유지보수 되도록 만드는 것이다. 시스템 아키텍처는 시스템이 제대로 동작하기를 최우선 목표로 삼는 것은 당연하나 아키텍처가 엉망이더라도 시스템은 제대로 동작할 가능성이 크다. 사실상 아키텍처는 운영보다 배포, 유지보수, 개발을 쉽게 하는데에 초점이 맞춰져야 한다. 아키텍처의 주된 목적은 시스템의 생명주기를 지원하는 것이다. 좋은 아키텍처는 시스템을 쉽게 이해하고, 쉽게 개발하며, 쉽게 유지보수하고, 또 쉽게 배포하게 해준다. 아키텍처의 궁극적인 목표는 시스템의 수명과 관련된 비용은 최소화하고, 프..
ISP와 언어 정적 타입 언어는 import, use, include 등과 같은 선언문을 사용해야 한다. 이로 인해 소스 코드 의존성이 발생하는데, 루비나 파이썬과 같은 동적 언어는 이러한 의존성이 아예 없어서 정적 타입 언어를 사용할 때보다 결합도가 낮은 시스템을 만들 수 있다. ISP와 아케틱처 시스템을 만들 때 특정 프레임워크를 사용하기로 강제로 결정을 내리고, 해당 프레임워크는 특정 데이터베이스를 강제로 사용해야 한다면, 시스템은 결국 데이터베이스까지 의존성을 가지게 된다. 이는 데이터베이스에 변경사항이 발생하면 프레임워크도 재컴파일 및 재배포를 해야 하고, 그렇게 되면 시스템도 재컴파일 및 재배포를 해야 한다. 또한 시스템이 전혀 사용하지 않는 데이터베이스의 특정 기능이 문제를 일으키면 시스템에..
책에서 리스코프 치환 원칙을 위반하는 좋은 예제를 정사각형/직사각형 문제로 보여준다. 사각형이라는 인터페이스가 있고 사각형 인터페이스는 가로 설정, 세로 설정 메서드를 제공한다. 그리고 이를 구현한 구현체는 직사각형 구현체와 정사각형 구현체가 있다. 사용자가 사각형 인터페이스를 사용할 때, 가로 설정과 세로 설정을 모두 사용한다고 가정하면 정사각형의 구현체를 사용한 사람은 해당 메서드가 원하는대로 동작하지 않을 것이다. 사용하는 입장에서 사용하는 것의 정확한 구현체를 알아야 한다면 이는 리스코프 치환 원칙에 위배된다. LSP는 아키텍처 수준까지 확장할 수 있고, 반드시 확장해야만 한다. 치환 가능성을 조금이라도 위배하면 시스템 아키텍처가 오염되어 상당량의 별도 메커니즘을 추가해야 할 수 있기 때문이다.
소프트웨어 개체는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다. 의존성 방향이 향하는 것은 화살표가 시작하는 곳의 변경사항을 화살표가 향하는 곳에서 지키기 위해서다. 만약 A -> B 로 화살표가 향한다면, A의 변경사항이 B에 영향을 주지 않게 하기 위함이다. 따라서 가장 중요한 비즈니스가 담긴 로직은 화살표를 받기만 하는 것이 좋고, 세부 사항으로 내려갈 수록 다른 것들을 의존해야 한다. 이런 화살표를 제어할 수 있는 가장 좋은 방법이 Interface 를 사용하는 것이다. OCP는 시스템 아키텍처를 떠받치는 원동력 중 하나다. OCP의 목표는 시스템을 확장하기 쉬운 동시에 변경으로 인해 시스템이 너무 많은 영향을 받지 않도록 하는 데 있다. 이러한 목표를 달성하려면 시스템을 컴포넌트 단위..
단일 책임 원칙은 함수는 단 하나의 일만 해야 한다는 원칙이 아니라 사실은 "단일 모듈은 변경의 이유가 하나, 오직 하나뿐이어야 한다." 라는 의미이다. 우발적 중복 단일 책임 원칙을 위반하는 대표적 사례인 우발적 중복을 살펴보자. Employee 클래스가 아래 세 가지 메서드를 가지고 있다. calculatePay() : 회계팀에서 기능을 정의하며, CFO 보고를 위해 사용 reportHours() : 인사팀에서 기능을 정의하며, COO 보고를 위해 사용 save() : 데이터베이스 관리자가 기능을 정의하며, CTO 보고를 위해 사용 calulatePay() 메서드와 reportHours() 메서드가 업무 시간을 계산하는 regularHours() 메서드를 동시에 사용한다고 했을때 CFO 팀에서 업무 ..
