23. 프레젠터와 험블 객체 험블 객체 패턴 행위들을 두 개의 모듈 또는 클래스로 나눈다. 이들 모듈 중 하나가 험블 가장 기본적인 본질을 남기고, 테스트하기 어려운 행위를 모두 험블 객체로 옮긴다. 험블 객체 패턴을 사용하여 행위를 분리 가능 프레젠터와 뷰 뷰는 험블 객체이고 테스트하기 어렵다. 프레젠터는 테스트하기 쉬운 객체다. 프레...

22. 클린 아키텍처 시스템 아키텍처와 관련된 여러가지 아이디어 육각형 아키텍처(Hexagonal Architecture) DCI(Data, Context and Interaction) BCE(Boundary-Control-Entity) 이들의 목표는 관심사의 분리(separation of concerns) 이들 아키텍처는 모두 ...

21. 소리나는 아키텍처 아키텍처의 테마 소프트웨어 아티텍처는 시스템의 유스케이스를 지원하는 구조 아키텍처를 프레임워크 중심으로 만들어버리면 유스케이스가 중심이 되는 아키텍처는 절대 나올 수 없다. 아키텍처의 목적 좋은 아키텍처는 유스케이스를 그 중심에 두기 때문에, 지원하는 구조를 아무런 문제없이 기술할 수 있다. 좋은 소프트웨어 아키텍처...

20. 업무 규칙 애플리케이션을 업무 규칙과 플러그인으로 구분하려면 업무 규칙이 실제로 무엇인지를 잘 이해해야만 한다. 업무 규칙은 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차 핵심 업무 규칙(Critical Business Rule): 사업 자체에 핵심적이며, 그대로 존재 핵심 업무 데이터(Critical Business D...

19. 정책과 수준 소프트웨어 시스템이란 정책을 기술한 것 대다수의 주요 시스템에서 하나의 정책은 이 정책을 서술하는 여러 개의 조그만 정책들로 쪼갤 수 있다. 소프트웨어 아키텍처를 개발하는 기술에는 이러한 정책을 신중하게 분리하고, 정책이 변경되는 양상에 따라 정책을 재편성하는 일도 포함된다. 흔히 아키텍처 개발은 재편셩된 컴포넌트 들을 비순...

18. 경계 해부학 경계 횡단하기 런타임에 경계를 횡단한다. 적절한 위치에서 경계를 횡단하게 하는 비결은 소스 코드 의존성 관리에 있다. 두려운 단일체 아키텍처 경계 중에서 가장 단순하며 가장 흔한 형태는 물리적으로 엄격하게 구분되지 않은 형태 배포 관점에서 볼 때 단일체는 경계가 드러나지 않는다. 이러한 아키텍처는 거의 모든 경우에 특정...

17. 경계: 선 긋기 소프트웨어 아키텍처는 선을 긋는 기술 아키텍트의 목표는 필요한 시스템을 만들고 유지하는 데 드는 인적 자원을 최소화하는 것 인적 자원의 효율을 떨어뜨리는 요인 -> 결합(coupling) 어떻게 선을 그을까? 그리고 언제 그을까? 의존 화살표의 방향으로 알 수 있다. 플러그인 아키텍처 소프트웨어 개발 기술의 역...

16. 독립성 좋은 아키텍처는 다음을 지원해야 한다. 시스템의 유스케이스 시스템의 운영 시스템의 개발 시스템의 배포 유스케이스 시스템의 아키텍처는 시스템의 의도를 지원해야 한다. 아키텍처는 시스템의 행위에 그다지 큰 영향을 주지 않는다. 행위를 명확히 하고 외부로 드러내며, 이를 통해 시스템이 지닌 의도를 아키텍처 수준에서...

15. 아키텍처란? 소프트웨어 아키텍트는 프로그래머이며, 앞으로도 계속 프로그래머로 남는다. 소프트웨어 아키텍트는 최고의 프로그래머이며, 앞으로도 계속 프로그래미 작업을 맡은 뿐만 아니라 동시에 나머지 팀원들이 생산성을 극대화할 수 있는 설계를 하도록 방향을 이끌어 준다. 소프트웨어 시스템의 아키텍처란 시스템을 구축했던 사람들이 만들어낸 시스템의...

14. 컴포넌트 결합 ADP: 의존성 비순환 원칙(Acyclic Dependencies Principle) 컴포넌트 의존성 그래프에 순환이 있어서는 안 된다. 많은 개발자가 동일한 소스 파일을 수정하는 환경에서 문제 발생 해결책: 주 단위 빌드, 순환 의존성 제거 주 단위 빌드(Weekly Build) 5일 중 4일 동안 각자 개발/1일 동...