소프트웨어 아키텍처, 도메인

원티드 프리온보딩 백엔드 챌린지 참여 중, 소프트웨어 아키텍처와 도메인의 정의에 대해 생각해보고 이해하는 시간을 가질 수 있었다. 강의 내용을 요약하면서 떠오른 생각들도 정리해보고자 한다.
 
 
 

소프트웨어 아키텍처

 

• 의의

아키텍처 선택은 시스템의 골격 역할, 품질 속성에 영향을 미치며 시스템을 제안한다.   -적정 소프트웨어 아키텍처
 
 
 

• 종류

모놀리식 아키텍처 : 단일 시스템 하에서 배포  ex) Layered / Clean / Hexagonal
=> 배포 용이
=> 유지보수 어려움, 한정된 트래픽, 부분 수정/오류 발생 시 전체에 영향
 
분산형 아키텍처 : 도메인별로 서버 분리하여 배포  ex) Service-oriented / Event-based / Microservice
=> 높은 확장성, 부분 수정/오류 발생 시 전체에 영향 X 
=> 오류 트래킹 시 여러 서버에 시도해야 하므로 시간 오래 걸림
 
 
 

• 구조가 잘 잡힌 애플리케이션

요구사항, 오류에 대해서 대응이 빠름
변경 빠름
확장성이 좋음  
좋은 아키텍처 구조를 가짐 => 경계가 뚜렷한 아키텍처
 
 
 
내가 진행한 사이드 팀프로젝트는 소규모 서비스이다 보니 큰 고민 없이 평소 학습하고 실습해온, 그리고 다른 레퍼런스들에서 적용하는 레이어드 아키텍처를 사용했다. 앞으로는 서비스 규모, 예상 트래픽, 목표 등을 고려하며 어떤 아키텍처를 선택할지에 대한 고민을 거친 후 선택할 예정이다.
 
 
 
 

도메인

 

• 정의

문제를 해결하기 위해 사용자가 프로그램을 사용하는 분야 => 문제 해결점, 비즈니스의 중심
 
ex. 회원/주문/결제/배송
 
 
 

• 반 버논식 구분

메인 도메인 : 비즈니스의 전체 도메인
서브 도메인 : 메인 도메인에서 나눠지는 하위 도메인
  - 핵심 도메인 : 서브 도메인 중 가장 중요한 비즈니스
  - 지원 서브 도메인 : 서브 도메인 중 필수적이지만 핵심은 아닌 도메인 (비즈니스적으로 연관이 되어야하는 도메인)
  - 범용 서브 도메인 : 필수적이지 않지만 전체 비즈니스를 위해 사용되는 도메인
 
 
 
프로젝트를 하면서 공유피드에 대해 말할 때 피드 도메인이라고 무심코 말했었는데 이런 접근에서는 도메인이 아니라 피드 서비스나 기능이라고 명명하는 게 더 적절했던 것 같다. 그리고 도메인 구분 관련해서 찾아보는데 범용 서브 도메인 예시로 회원 도메인이 있었다. 회원이 왜 필수적이지 않은 도메인으로 분류되는 건지 궁금해서 더 찾아봐야겠다.