아키텍처는 레이어,서비스,필터에 대해 이야기 하지만, 코드는 패키지, 클래스 ,메서드를 구현해야한다
모델을 코드에 담는 가장 간단한 방법은 아키텍처의 어휘를 그대로 사용하는것이다
레이어를 사용하는경우 코등에서도 레이어라고 이름짓는다. 파이프와 필터 패턴을 채택한 경우 클래스 이름도 파이프와 필터로 지정한다.
시스템을 조종사와 네비게이터에 비유하며 이야기 했다면, 이 단어를 코드에도 타입과 인스턴스의 이름으로 사용한다.
객체와 관계의 매퍼나 액터 기반 시스템 등 많은 프레임워크는 구현체 안에 도메인 모델이 이미 있다고 가정하면, 도메인 모델이 없는 경우라도 도메인 모델이 있을 때 프레임 워크가 의도대로 더 잘 동작하도록 구현되어 있다, 이처럼 코드에 도메인 모델을 전제하고 구현하는 방식은 도메인 주도설계 DDD를 비롯한 여러 설계 방법론의 핵심 원칙이다
좋은 이름 짓기는 시작에 불과하다. 코드를 어떻게 구성하느냐에 따라 아키텍처 구조도 영향을 받는다. 자바 컴파일러의 경우 여러 클래스를 하나의 파일에 넣든 논리적으로 나누든상관없이 컴파일된다.
모듈구조
코드로 읽기엔 가장 수월하지만, 제어하기엔 어려움이 많다. 현대적인 프로그래밍 언어에서는 모듈이 접근을 제어함으로써 사용 가능성을 제한 할 수 있다.
요소 간에 관계를 제어하지 못하면 적어도 확인할 수 있어야한다.
아키텍처를 위반할 때 시스템이 빠르게 실패하도록 설계하는 방법이 있다 '계약에 의한 설계'는 사전조건, 사후조거느 불변조건을 코드에 추가하고 실행할 때 관계를 확인하는 제어방식이다.
할당구조에서 코드로 의도를 표현하기 어렵다
서비스현 플랫폼 paas 도커같은 컨테이너 기술,코드로 관리하는 인프라 깃 같은 분산형 버전 제어 시스템 등의 기술과 패러다임의 발전으로 할당 구조 모델을 코드로 표현하거나 제어할 수 없다.
코드로는 모델마나 표현한다. 좋은 이름을 짓고 알려진 패턴을 적절히 사용해 코드에 몇 가지 논리적 근거를 넣을 수 있다.
모델을 코드에 담지 못하거나 코드로 보여줄 수 없을지라도, 시스템이 모델을 생성하게 할 수 도 있다. 프로그래밍 언어나 기술,패턴에 따라 다르겠지만, 생성된 모델로 규약을 점검하거나 설계상의 변화를 자동으로 모니터링 할 수 있다.
근래의 거의 모든 객체지향 언어느 코드로부터 통합 모델링 언어 클래스와 패키지 다이어그램을 생성할 수 있다. 대부분의 프로그래밍 언어에는 종속성 분석도구가 있다. 이처럼 생성된 모델을 사용해 모듈 구조를 분석 할 수 있다.
컴포넌트와 커넥터 구조는 자동으로 모델을 생성하기가 어렵다. 컴포넌트와 커넥터 구조를 생성하려면 실행 중인 모델을 관찰할 수 있도록 계측 기능을 추가하는 편이 좋다
다양한 관점으로 아키텍처 표현하기
요소-역학 뷰로 요소 역할 보여주기
구체화 뷰로 확대/축소하기
품질속성뷰로 품질 속성 충족 여부 보여주기
매핑뷰로 여러 뷰의 요소 연결하기
카툰으로 아이디어 표현하기
커스텀 뷰로 의미있는 내용 보여주기
멋진다어그램 그리기
조직구성
기술과 비즈니스 이해관계자들의 어휘통일
품질속성강조
생각의 명료화
평가 대상 파악
GQM 접근법,이해관계자 인터뷰
가정나열하기
품질 속성 레이다 차트
미니 품질 속성 워크숍
관점 매드립
허수아비 반응
이해관계자맵
컴포넌트-역할카드
개념도
나눠서 정복하기
이벤트 스토밍
그룹 포스터
라운드 로빈설ㅖ
화이트보드 토론
ADR - 글로 작성된 템플릿을 사용해 아키텍처 설계
아키텍처 하이쿠
콘텍스트 다이어그램
인기독서목록
인덱션덱
모듈식 분해 다이어그램
가지않는길
프로토타입
시퀀스다이어그램
시스템 메타포
아키텍처 브리핑
코드리뷰
의사결정 매트릭스
관측하기
질문-코멘트-우려사항
리스크 스토밍
온전성 검사
시나리오 훑어보기
스케치하고 비교하기
출처-개발자에서 아키텍트로
사실 입문자가 실무에대해서 이해하기 어려운부분이 있었지만, 시각화 보여주기에 대해서 기초적으로 알 수 있어 앞으로 설계를 시작할때 참고하기 좋았던것 같다.