아키텍처란?
이 글은 빨리 공유하고 싶은 마음에 잘 정리가 안된 상태로 공유를 하는 것 같다. 꼭 원문을 읽어들 보시기 바란다.
소프트웨어 아키텍트에게 어떤 데이터베이스, 프레임워크, 웹서버 등을 사용할 것인지가 중요한 것이 아니다.
비즈니스 로직이 중요하다. 비즈니스 로직은 어떤 데이터베이스가 사용될지 알 필요가 없어야 한다. 데이터베이스에 독립적이어야 한다는 말이다. 그래야 데이터베이스가 변경되어도 비즈니스 로직은 재사용될 수 있다.
우리가 재사용해야 하는 것은 데이터베이스, 프레임워크 등과 같은 Low Level Details이 아니라 High Level Policy에 해당하는 비즈니스 로직이다.
이를 이루기 위해 필요한 것이 DIP(Dependency Inversion Principle)이다. DIP를 통해 High Level Policy는 Low Level Detail을 호출하지만 의존성은 역전되게 된다.
객체지향이 하는 것은 다른 객체에게 메시지를 전달하는 것이다. 메시지 전송 객체는 수신 객체가 구체적으로 어떤 타입인지 모른다. 아키텍처의 원칙은 전송 객체가 수신 객체가 구현해야 하는 인터페이스를 정의(소유)한다는 것이다. DIP가 이를 구현하는 원칙이다. High Level Policy가 사용할 Interface는 High Level Policy와 같은 패키지에 속하고, 실제 이 인터페이스의 구현체인 Low Level Detail은 다른 패키지에 존재하고, High Level Policy 패키지에 의존성을 갖는다.
ISP(Interface Segregation Principle)
각 비즈니스 객체는 자신의 필요로 하는 데이터 접근 기능에 대한 인터페이스를 정의한다. 이처럼 자신이 사용할 인터페이스를 스스로 정의하는 것이 ISP에 해당한다.
각 비즈니스 객체는 데이터베이스 기능 중에 자신이 정의한 인터페이스에 있는 기능만을 사용한다. 이 말은 데이터베이스 기능을 위해 많은 인터페이스와 구현체가 있어야 한다는 것을 의미한다. 시간 낭비로 보일 수 있지만 이게 깨끗한 설계를 위해서 필요하고, 시간을 절약하는 방법이다. 이게 부적절한 결정을 미룰 수 있는 중요한 아키텍처 관련 결정이다.
소프트웨어 아키텍트가 되고자 하는가? 정말로 중요한 결정을 하고자 원하는가?
어떤 데이터베이스, 웹서버, 프레임워크를 쓸 것인지가 중요한 결정이 아니다.
소프트웨어 아키텍트에게 중요한 결정은 어떤 데이터베이스, 웹서버, 프레임워크를 쓸 것인지를 결정하지 않아도 되도록 하는 것이다. 이런 결정은 초기에 할 것이 아니라 충분한 정보가 있을 때까지 결정을 미룰 수 있도록 하는 것이 중요하다.
