34. 빠져 있는 장 프레임워크는 아키텍처가 될 수 없다. 계층 기반 패키지 수평 계층형 아키텍처 처음 시작하기에 적합 Controller, Service, Repository 엄청난 복잡합을 겪지 않고도 무언가를 작동시켜 주는 아주 빠른 방법 소프트웨어가 커지고 복잡해지기 시작하면, 더 잘게 모듈화를 해야 할지 고민하게 됨 업무 도메인...

32. 프레임워크는 세부사항이다 프레임워크는 아키텍처가 될 수 없다. 프레임워크 제작자 프레임워크는 당신이 풀어야 할 특별한 관심사를 염두에 두지 않는다. 물론 당신의 문제는 프레임워크가 풀려는 문제와 꽤 많이 겹친다. 혼인 관계의 비대칭성 당신은 프레임워크를 위해 대단히 큰 헌신을 해야 하지만, 프레임워크 제작자는 당신을 위해 아무런 헌신...

31. 웹은 세부사항이다 끝없이 반복하는 추 연산 능력을 중앙에 집중하는 방식과 분산하는 방식 사이에서 끝없이 움직인다. 애플리케이션을 보호하기 위해 업무 규칙을 분리해야 함 요약 GUI는 세부사항. 웹은 GUI. 따라서 웹은 세부사항 참조 클린 아키텍처(Clean Architecture)

30. 데이터베이스는 세부사항이다 아키텍처 관점에서 볼 때 데이터베이스는 엔티티가 아니다. 데이터베이스는 데이터에 접근할 방법을 제공하는 유틸리티일 뿐 관계형 데이터베이스 관계형 데이터베이스는 세부사항임 데이터가 테이블 구조를 가진다는 사실은 오직 아키텍처의 외부 원에 위치한 최하위 수준의 유틸리티 함수만 알아야 함 데이터베이스 시스템은 왜...

29. 클린 임베디드 아키텍처 소프트웨어는 닳지 않지만, 펌웨어와 하드웨어는 낡아 가므로 결국 소프트웨어도 수정해야 한다. 소프트웨어는 닳지 않지만, 펌웨어와 하드웨어에 대한 의존성을 관리하지 않으면 안으로부터 파괴될 수 있다. ROM에 상주하는 코드만이 펌웨어는 아니다. 무엇에 의존하는지, 그리고 하드웨어 발전에 맞춰 수정하기가 얼마나 어려운...

28. 테스트 경계 시스템 컴포넌트인 테스트 아키텍처 관점에서 모든 테스트는 동일 테스트는 태생적으로 의존성 규칙을 따른다. 의존성은 항상 테스트 대상이 되는 코드를 향함 시스템 내부의 어떤 것도 테스트에는 의존하지 않으며, 테스트는 시스템의 컴포넌트를 향해 항상 원의 안쪽으로 의존 테스트는 독립적으로 배포 가능 테스트는 시스템 컴포넌트 ...

27. ‘크고 작은 모든’ 서비스들 서비스 지향 아키텍처와 마이크로서비스 아키텍처는 최근에 큰 인기을 얻고 있는 이유 서비스를 사용하면 상호 결합이 철저하게 분리되는 것처럼 보인다. 사실 일부만 맞는 말 서비스를 사용하면 개발과 배포 독립성을 지원하는 것처럼 보인다. 사실 일부만 맞는 말 서비스 아키텍처 서비스 그 자체로는 아키텍처를...

26. 메인(Main) 컴포넌트 모든 시스템에는 최소한 하나의 컴포넌트가 존재하고, 이 컴포넌트가 나머지 컴포넌트를 생성하고, 조정하며, 관리한다. -> 메인 컴포넌트 궁극적인 세부사항 메인 컴포넌트는 궁극적인 세부사항으로, 가장 낮은 수준의 정책 의존성 주입 프레임워크를 이용해 의존성을 주입하는 일은 바로 이 메인 컴포넌트에서 이뤄져야 ...

25. 계층과 경계 흐름 횡단하기 시스템이 복잡할수록 컴포넌트 구조는 더 많은 흐름으로 분리됨 흐름 분리하기 복잡 결론 아키텍처 경계는 어디에나 존재한다. 경계를 제대로 구현하려면 비용이 많이 든다. 이러한 경계가 무시되었다면 나중에 다시 추가하는 비용이 크다. 목표를 달성하려면 빈틈없이 지켜봐야 한다. 참조 클린 아키텍처(C...

24. 부분적 경계 마지막 단계를 건너뛰기 부분적 경계를 생성하는 방법 하나는 독립적으로 컴파일하고 배포할 수 있는 컴포넌트를 만들기 위한 작업은 모두 수행한 후, 단일 컴포넌트에 그대로 모아만 두는 것이다. 이처럼 부분적 경계를 만들려면 완벽한 경계를 만들 때 만큼의 코드량과 사전 설계가 필요하다. 하지만 다수의 컴포넌트를 관리하는 작업은 하...