Robert C. Martin는 책에서 설계적인 측면에서 좋은 소프트웨어 설계는 필요한 시스템을 만들고 유지보수하는데 투입되는 비용을 최소화하는데 있다고 이야기 합니다.
좋은 소프트웨어 시스템은 깔끔한 코드로부터 시작합니다. 좋은 아키텍쳐를 정의하는 원칙으로 SOLID 원칙을 들고 있습니다. SOLID 원칙의 목적은 중간(모듈) 수준의 소프트웨어 구조가 변경에 유연하며, 이해하기 쉽고, 많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트의 기반이 되도록 하는데 있다고 합니다.
#정책# 좋은 아키텍쳐의 목표는 시스템에서 정책을 가장 핵심적인 요소로 식별하고, 동시에 세부사항은 정책에 무관하게 만들 수 있는 형태로 구축하는 것이라고 이야기 합니다. 예를 들자면, 개발 초기에 데이터베이스가 어떤 데이터베이스인지, 어떤 웹 서버를 사용할 것인지 등에 영향을 받아서는 안된다는 내용입니다. 세부사항에 몰두하지 않은채 고수준의 정책(핵심적인 요소)를 구분할 수 있다면 이러한 세부사항(데이터베이스, 웹 서버)에 대한 결정을 오랫동안 미루거나 연기할 수 있습니다.
#경계# Robert C. Martin은 소프트웨어 아키텍쳐는 선을 긋는 기술이라고 말을 하며, 이러한 선을 경계(Boundary)라고 합니다. 경계는 소프트웨어 요소를 서로 분리하고, 경계 기준으로 반대편에 있는 요소를 알지 못하도록 막는 역할을 합니다. 경계는 보통 각 레이어를 기준으로 나뉘게 됩니다. 제어의 흐름은 저수준에서 고수준을 향하게 됩니다. 따라서 저수준 모듈은 고수준 모듈을 알 수 있지만 고수준은 저수준을 알 수 없습니다. 이것을 가능하게 하는 것이 추상화와 의존성 역전 원칙(DIP)입니다.
또 레이어간 의존성 규칙을 지키기 위해서 2가지 사항을 고려해야 합니다. 1. 객체는 항상 고립되어야 합니다. 즉, 언어의 기본 형태를 사용해야 하고 감춰진 의존성을 가지면 안됩니다. 2. 고수준에서 저수준에 직접 참조하게 될 때, Interface를 통해 저수준의 세부사항 대신 호출해야하는 대상만 알게 해야합니다.
#Business Rules# 이것은 소프트웨어 시스템이 존재하는 이유이며 핵심입니다. 아키텍처에 대해서 얘기할 때, 비즈니스 룰(Entity, UseCase)이 존재하는 Layer가 가장 중요합니다. 이 Layer는데이터베이스 UI와 같은 저수준 관심사로 인해 영향을 받아선 안됩니다. 비즈니스 룰은 시스템에서 가장 독립적이며 가장 많이 재사용 가능한 코드여야 합니다.
#Entity# 엔티티는 컴퓨터 시스템 내부의 객체로서, 핵심적인 데이터 가지고 있으며, 그것을 기반으로 동작하는 핵심적인 비즈니스 룰을 구체화합니다. 엔티티 객체는 핵심 데이터를 직접 포함하거나 핵심 데이터에 매우 쉽게 접근할 수 있습니다. 엔티티의 인터페이스는 핵심 데이터를 기반으로 동작하는 핵심 비즈니스 룰을 구현한 함수들로 구성됩니다. 이러한 Entity는 완전히 독립적인 존재여야 하며, 데이터베이스, UI, 프레임워크에 고려사항들로부터 자유로워야 합니다.
#UseCase# 모든 비즈니스 룰이 엔티티처럼 순수한 것은 아닙니다. 유스케이스는 사용자가 제공해야 하는 입력, 사용자에게 보여줄 출력, 그리고 해당 출력을 생성하기 위한 처리 단계를 기술합니다. 쉽게 말해서 엔티티와 사용자 사이의 상호작용을 규정하는 역할입니다. 엔티티가 엔터프라이즈에 특화된 비즈니스 룰을 담당한다면 유즈케이스는 애플리케이션에 특화된 비즈니스 룰을 담당합니다. 엔티티를 제어하는 것이 유즈케이스입니다.
#Test# 아키텍쳐가 프레임워크와는 거리를 두고 유즈케이스를 최우선으로 설계 되었다면, 유스케이스 전부에 대하여 단위 테스트를 할 수 있어야 합니다. 그렇기 때문에 엔티티는 어디에도 의존하지 않는 순수한 객체(POJO)여야 합니다.
#요약# 1. 프레임워크로부터 독립적입니다. 2. 외부적인 요인(DB, Web Server 등등) 없이도 테스트가 가능합니다. 3. 제대로 적용한다면 저수준의 변동사항이 고수준에 영향을 주지 않기때문에 유지보수에 용이합니다.
댓글