유스케이스

<aside> 💡

유스케이스란, 시스템이 어떤 서비스 / 기능을 제공 해 주는지 명세 해 놓은 것

</aside>

• 시스템 아키텍처는, 시스템의 의도를 지원 해야 함
• 장바구니에 관련된 응용 프로그램이라면, 장바구니와 관련된 유스케이스를 지원 해야 함
• 아키텍처는, 행위를 명확히 하고 외부로 드러내며, 시스템이 지닌 의도를 아키텍처 수준에서 알아 볼 수 있도록 만들어야 함
• 행위 ( 실제 구조를 구현한 구현체 )를 모르는 사람이 아키텍처를 보더라도, 어떻게 개발 해 나갈지 명확하게 그려 나갈 수 있도록 아키텍처를 구성 하는 것이 좋음
• 구체적인 개발 명시 없이 의도를 명확히 표출 해 낼 수 있어야 함

운영

• 운영 측에서 요구하는 기능이 명확하게 있다고 할 지라도, 아키텍처와 이 기능을 구체적으로 어떻게 구현 할 지는 독립적으로 존재 해야 함
• 컴포넌트를 적절히 격리한 상태로 통신하는 형태로 구축 해 놓는다면, 시간이 지나 구체적인 요구사항이 바뀐다 하더라도 정책적인 방향은 바뀌지 않고도 서비스를 운영 할 수 있음

개발

• 각 팀별로 아키텍처가 있을 수 있으며, 조직의 의사소통 구조와 동일한 구조의 설계를 가지게 됨
• 각 팀이 독립적으로 행동하기 위해선, 컴포넌트 단위로 아키텍처를 쪼갤 수 있어야 함

배포

• 컴포넌트 단위로 적절하게 분할하고 격리된 아키텍처는, 빌드 후 바로 배포 할 수 있는 특징을 가짐
• 빌드 된 후 즉각 배포 할 수 있도록 지원 해 주어야 함

계층 결합 분리

• 아키텍트는 필요한 모든 유즈케이스를 지원 할 수 있는 시스템 구조를 원하지만, 유즈케이스 전부를 알수는 없음
• 하지만, 시스템의 기본적인 의도 ( 어떤 결제를 할 것인지, 어떤 서비스를 제공하는지 등 )는 알고 있기 때문에, SRP / OCP를 적용하여 다른 이유로 변경되는 것들을 분리, 동일한 이유로 변경되는 것들을 묶어야 함
• 입력 필드 유효성 검사는 응용 프로그램과 밀접하게 연관된 로직