[Architecture Pattern] SoftWare Architecture

아키텍처(Architecture)란 위키피디아에 따르면

"소프트웨어의 구성요소들 사이에서 유기적 관계를 표현하고 소프트웨어의 설계와 업그레이드를 통제하는 지침과 원칙"을 의미한다. 

말이 어렵지만, 아키텍쳐(Architecture)를 한국말로 직역하면 "구조"다. 

즉, SW 아키텍쳐란 SW구조를 말한다.

 

좋은 집을 설계하기 위해 집의 구조(도면)를 잘 설게 해야 하듯이, 

좋은 SW를 위해 SW 아키텍쳐를 잘 설계해야 한다.

 

그렇다면 좋은 SW, "좋은 품질의 SW"란 무엇일까?

일반적으로 사용자에게 좋은 서비스를 제공하는 것만으로는 "좋은 품질의 SW"라 부르지 않는다.

SW의 품질은 2가지로 나뉘는데, 이는 단순히 External Quality를 만족한 것에 지나지 않는다.

• External Quality 
• Internal Quality  

좋은 "Internal Quality"를 가진 SW는 

시간이 지날수록 기능을 추가하기 쉽고, 유지보수와 테스트에도 용이하다.

즉, "소프트웨어 아키텍쳐(Architecture)"란,

소프트웨어가 좋은 Internal Quality와 External Quality를 가지도록 하는 구조이다.

 

 

Separation Of Concerns (SoC)

좋은 소프트웨어 아키텍쳐를 위해

고려해야 하는 것 중 하나가 "관심사의 분리(SoC)"이다.

"관심사의 분리"는 Application의 코드를 잘 나누는 것을 말한다.

 

간단한 TODO앱이라 할지라도 코드의 양은 생각보다 많다. 

만약 이를 하나의 뭉터기로 구현하게 된다면, 

가독성, 기능 추가, 유지보수 등 여러 측면에서 단점을 가지게 된다.

따라서, 코드들을 관심사를 기준으로 잘 나눠주어야 한다. 

 

물리적으로 코드를 나누는 것만으로는 "코드를 나눴다"라고 말하지 않는다. 

잘 나뉜 코드는 높은 결합도와 낮은 응집도를 갖는다. 

• 결합도 : 모듈 내부의 기능적인 집중도를 의미
• 응집도 : 모듈간의 상호 의존도를 의미

Architecture단에서 관심사는 로직으로 나누게 된다.

UI 로직은 자주 변하기 때문에, 이를 Buisness 로직과 분리하게 된 게 MVC Pattern이다.

 

이렇듯, "Architecture Pattern"이란,

집의 설계도를 A형 설계도, B형 설계도, C형 설계도로 패턴화 시켜놓은 것과 같이, 

MVC, MVVM, RIBs Pattern  등등 소프트웨어 아키텍쳐를 패턴화 시켜놓은 것이다.

 

 

Buisness(Domain) Logic 

소프트웨어는 기본적으로 "현실세계의 문제"를 풀기 위해 설계된다.

예를 들어, 쇼핑몰 어플은 "사용자에게 스마트폰으로 쇼핑"이라는 문제를 풀기 위해 설계된다.

 

따라서, 문제를 해결하기 앞서

문제 영역(Problem Space)과 해결 영역(Solution Space)을 고려해야 할 필요가 있다.

이러한 문제영역을 "Domain"이라 부른다. 

앞선 쇼핑몰 예시에선 "쇼핑"이라는 문제가 Domain이 된다.

이는 또 다시 "구매", "장바구니", "회원가입" 등등 SubDomain으로 나뉘게 된다.

 

이러한 "현실세계의 문제"를 해결하기 위한 코드를 Domain(Buisness) Logic이라 부른다.

즉, Solution Space에 속한다.

 

해당 Domain을 해결하기 위해선, 많은 코드들이 작성된다. 

쇼핑몰 "구매"라는 문제를 해결하기 위한 코드를 예시로 들어보자.

• 제품의 제고가 충분한지 확인한다.
• 충분하다면 결제 진행을, 충분하지 않다면 에러 메시지를 띄운다. 
• DB에서 사용자의 계좌 잔액을 조회한다. 
• 계좌 잔액이 충분한지 확인한다. 
• 충분하다면 결제를 진행하고, 충분하지 않다면 에러 메시지를 띄운다. 
• 사용자의 잔액과 제품의 제고를 감소시킨다.
• 감소된 잔액을 DB에 저장한다.

이 모든 코드들이 Domain Logic이 되지는 않는다.

Domain Logic은 "현실문제에 대한 의사결정(Decision)"을 하는 코드이다.

• 제품의 제고가 충분한지 확인한다. (해당 상품을 구매할 수 있는지에 대한 의사결정)
• 계좌 잔액이 충분한지 확인한다. (상품을 결제할 수 있는지에 대한 의사결정)
• 사용자의 잔액과 제품의 제고를 감소시킨다. (구매라는 서비스를 수행)

 

나머지는 Applicatoin Service Logic이라 부르며, UI로직과 Data 관련 로직을 포함한다.

•  에러 메시지를 띄운다. (UI로직)
• DB에서 사용자의 계좌 잔액을 조회한다. (외부 디펜던시 관련 로직)
• 감소된 잔액을 DB에 저장한다. (외부 디펜던시 관련 로직)

 

 

Business(Domain) Logic와 UI Logic분리

Business Logic에 비해 UI Logic은 자주 변한다. 

만약 이 둘이 하나의 관심사로 묶이게 된다면, 

UI Logic에서만 이루어진 변화는 Business Logic의 변화로 이루어지게 될 것이다. 

 

따라서, UI Logic과 Business Logic을 분리하고자 한 것이

MVC, MVVM, MVP와 같은 MV* 계열 Architecture Pattern이다.

 

Data 접근 관련 로직 분리

Data 관련 로직은 주로 외부에서 데이터를 가져오는 코드이다. 

이는 Buisness 로직과 특성도 변경 주기도 다르다.

예를 들어 Reqeust의 포멧이 바뀌게 된다면 Data 관련 로직은 변하게 된다. 

 

따라서, Data관련 로직을 Buisness Logic과 분리하는 Architecture Pattern들이 나오게 되었고, 

대표적으로 Clean Architecture와 Repository 패턴이 있다.

 

 

Architecture Pattern vs. Design Pattern

소프트웨어 Architecture는 "한 소프트웨어의 뼈대나 고수준의 기반을 담당"한다.

MVC, MVP, MVVM 등의 패턴들이 아키텍처 패턴에 속한다.  

 

반면, 소프트웨어 Design은 "각각의 모듈들이 어떤 것을 하는지, 클래스의 범위, 함수의 목적 등 코드 수준의 디자인을 담당"한다.

싱글톤, Observer 패턴, Delegate 패턴 등이 여기에 속한다. 

 

즉, 소프트웨어 Architecture은 소프트웨어 Design보다 더 넓은 범주에 속한다. 

집 설계를 빗대어 표현해보면,

소프트웨어 Architecture는 집 전체에 대한 설계(큰 그림)를 담당한다면, 

소프트웨어 Design은 각 방의 인테리어 혹은 구조등을 설계한다고 비유할 수 있다.

 

 

 

References

https://velog.io/@eddy_song/domain-logic

https://enterprisecraftsmanship.com/posts/what-is-domain-logic/

https://youtu.be/4E1BHTvhB7Y