- 비즈니스 개념에 따른 모델
인터페이스 안정성 : 비즈니스 경계로 나눔 > 기술적 개념에 맞춤
시스템이 동작하는 도메인을 모델링 -> 더 안정적인 인터페이스 형성
비즈니스 프로세스의 변경을 더 쉽게 반영 가능
- 자동화 문화의 적용
다루어야 하는 변경되는 부분의 수만으로도 복잡성이 증가
자동화 테스팅이 매우 중요
일관된 명령 호출 = 어디에서나 같은 방식으로 배포 + 지속적 배포
환경 정의, 커스텀 이미지, 불변 서버 등을 사용
- 내부 세부 구현의 은폐
경계가 있는 콘텍스트로 모델링 -> 공유되고 은폐되어야 하는 모델에 집중하게 도움
DB통합과 같은 결합 문제에 빠지지 않도록 데이터페이스도 감추어야 함
데이터 펌프 or 이벤트 데이터 펌프 -> 리포팅 목적으로 여러 서비스로부터 데이터를 통합
기술 중립적 API (REST)
- 모든 것을 분권화
셀프 서비스 : 요구할 때 언제든 배포, 개발과 테스팅을 가능한 쉽게, 별도의 팀이 이러한 활동을 수행할 필요가 없게
팀이 변경 및 변경 릴리즈 시점까지도 스스로 결정하게 하여 팀이 그들의 서비스를 소유하도록 보장
내부 오픈 소스를 이용하면 다른 팀이 소유한 서비스를 변경할 수 있지만 구현이라는 부가적인 일이 생긴다는 점을 기억
콘웨이의 법칙이 효과가 있도록 팀을 조정
공유 거버넌스 모델 : 각 팀의 사람들이 시스템의 기술 비전을 진화시킬 책임을 집단으로 공유
코레오그래피 아키텍처 : 서비스 경계 내에서 로직과 데이터 연관성을 보장하는 영리한 엔드포인트로 응집력을 유지 (오케스트레이션과 멍청한 미들웨어는 사용하지 않음)
오케스트레이션(orchestration)
오케스트라 지휘자처럼 프로세스를 아내하고 구동하는 하나의 중앙 두뇌에 의존
고객 서비스에 지나치게 많은 중앙 관리 권한이 부여되는 단점
매우 취약하고 높은 변경 비용 수반
코레오그래피(choreography)
발레 무용수들이 자신의 역할을 알고 주변의 다른 무용수에 반응하는 것처럼 시스템 각 부분에 작업 내용을 알리고 세부 사항을 수행
비동기 방식으로 이벤트 발산을 통해 느슨한 결합을 이끔
- 독립적인 배포
클라이언트 호환성을 깨는 변경이 필요할 때 시간을 두고 변경할 수 있도록 여러 버전의 엔드 포인트가 공존되도록 해야 함
RPC 기반의 통합을 한다면 Java RMI와 같은 강력히 결합된 클라이언트/서버 스텁의 생성은 피해야 함
호스트당 단일 서비스 모델 적용
청색/녹색 or 카나리아 릴리스 기법 : 잘못된 릴리스의 위험을 줄이며 릴리스와 배포를 분리
소비자 주도 계약 : 호환성을 깨뜨리는 변경을 미리 발견
- 장애 격리
원격 호출을 지역 호출처럼 처리하면 안됨 - 지나치게 추상화한 클라이언트 라이브러리 사용 X
안티프래질, 타임아웃, 격벽, 회로차단기
네트워크 파티션이 함축하는 것과 주어진 상황에서 가용성과 일관성 중 어느 것을 희생하는 것이 옳은 판단인지 알아야 함
- 매우 식별 가능한
합성(가상) 트랜잭션을 주입함으로써 실사용자의 행위를 모의하는 유의적 모니터링을 사용
로그와 통계를 수집
시스템 간 모든 호출을 추적할 수 있도록 상관관계 ID 사용