소프트웨어 아키텍처는 선을 긋는 기술이다. 이 선은 소프트웨어를 분리하고 이 선을 사이에 두고 한 쪽은 다른 쪽을 알지 못한다(반대는 알 수 있다). 결합을 줄이고 일찍 결정하지 않아도 되는 요소들을 나중으로 미루는 것이 선 긋기의 목표다.
어떻게 선을 그을까? 그리고 언제 그을까?
관련이 있는 것과 없는 것 사이에 선을 긋는다. GUI 와 비즈니스 로직은 관련이 없기 때문에 GUI 와 비즈니스 로직 사이에는 선이 그어져야 한다. 그리고 비즈니스 로직과 DB 사이에도 선이 그어져야 한다. 어떤 DB 를 사용하더라도 비즈니스 규칙이 그에 따라 변화되어서는 안된다.
이렇게 정하고 보면 인터페이스가 어떤 계층에 있어야 하는지 알게 된다. 기본적으로 스프링 컨트롤러 - 서비스 - 레포지토리 구조에서 DB 인터페이스는 서비스에 있고, 레포지토리에서 이를 구현한 구현체가 있어야 한다. 그래야 화살표의 방향이 레포지토리에서 서비스로 향하게 된다. 또 다르게 말하면 레포지토리에 인터페이스 없이 만든 구현체를 그대로 서비스에서 참조하여 쓰게 된다면 이는 레포지토리가 변경될 때 서비스에도 변경사항이 영향을 미칠 가능성이 존재하게 된다. 더 나아가 레포지토리를 쉽게 교체할 수 없게 만든다.
플러그인 아키텍처
DB 와 GUI 사이에 선을 그으면 이것을 플러그인 아키텍처로 이야기 할 수 있다. 비즈니스 로직은 가운데에서 그대로 있고, DB 와 GUI 를 플러그인으로 사용하는 것이다. DB 는 어떤 종류의 것을 사용해도 미리 정의한 인터페이스에 맞춰주기만 하면 된다. GUI 도 마찬가지다.
물론 이런 교체가 쉽다는 이야기는 아니지만 이러한 구조로 가져가게 된다면 변경을 가능하게 하는 것이 꿈은 아니다.
