6부 세부사항

30 데이터베이스는 세부사항이다.

아키텍처 관점에서 볼 떄 데이터베이스는 엔티티가 아니다. 즉, 데이터베이스는 세부사항이라서 아키텍처의 구성요소 수준으로 끌어올릴 수 없다.

 

관계형 데이터베이스

• 많은 데이터 접근 프레임워크가 테이블과 행이 객체 형태로 시스템 여기저기에서 돌아다니게 허용하는데, 아키텍처적으로 잘못된 설계다.

디스크가 없다면 어떻게 될까?

• 데이터를 파일이나 테이블 형태로 그대로 두는 경우는 거의 없다.

하지만 성능은?

• 성능은 시스템의 전반적인 아키텍처와는 아무런 관련이 없다.

32장 프레임 워크은 세부사항이다.

프레임워크 제작자

• 물론 당신의 문제는 프레임워크가 풀려는 문제와 꽤 많이 겹칠 것이다.
• 겹치는 영역이 크면 클수록 프레임워크는 실제로 더 유용해진다.

해결책

• 프레임워크를 사용할 수는 있다. 다만 프레임워크와 결합해서는 안된다. 적당히 거리를 두자.
• @Autowired 어노테이션이 업무 객체 도처에 산재해서는 안된다.
• 메인 컴포넌트에서 스프링을 사용해서 의존성을 주입하는 편이 낫다.

33장 사례 연구: 비디오 판매

유스케이스 분석

• 기존 기능을 변경해햐 한다면, 그 이유는 반드시 이들 액터 중 하나에게 해당 기능을 제공하기 위해서다.

34장 빠져있는 장

계층 기반 패키지

• 엄격한 계층형 아키텍처의 경우 계층은 반드시 바로 아래 계층에만 의존해야 한다.
• 소프트웨어가 커지고 복잡해지기 시작하면, 머지 않아 큰 그릇 세 개만으로는 모든 코드를 담기엔 부족하다는 사실을 깨닫고, 더 잘게 모듈화해야 할지를 고민하게 될 것이다.

기능 기반 패키지

• 이는 서로 연관된 기능, 도메인 개념, 또는 (도메인 주도 설계 용어를 사용한다면)Aggregate Root에 기반하여 수직의 얇은 조작으로 코드를 나누는 방식이다.