arawn/building-modular-monoliths-using-spring

스프링을 기반으로 모듈형 모노리스를 만들기 위한 방안을 공유합니다. Contribute to arawn/building-modular-monoliths-using-spring development by creating an account on GitHub.

GitHubarawn

내용을 오랫동안 기억하기 위해 정리합니다.

• 4 MSA 기술부채
  - 공유된 데이터 원본 (shared datastore)
  - 혼잡한 기능수행 (messy processing)
  - 동시배포 (deployment together)
• 우린 마이크로서비스에서 모노리틱으로 갈아탔다
• 6 모노리틱으로 되돌아가는 여정:  1) 프로젝트별 구조정리 -> 2) 저장소 및 프로젝트 통합 -> 3) 패키지 구조 표준화 -> 4) 서비스 통합
• 17 아키텍처 스타일이 문제를 해결해 주지 않고 큰 진흙 덩어리는 무얼 하든 만들 수 있다. 소프트웨어는 태생적으로 복잡하다. 의도적으로 복잡성을 제어하기 위해 높은 응집(Cohesion)도와 낮은 결합(Coupling)도를 다스리는게 품질을 결정하는 기준이 된다.

The devil is in the detail

• 18 소프트웨어의 개발의 목적은 긍정적인 비지니스의 영향력을 가능한한 빠른시간에 소비자에게 전달하는 것이다. 시장의 변화를 빠르게 지속적으로 수용하면서 규모가 커지더라도 속도가 떨어지지 않게 개발이 변화의 속도를 따라잡아야 한다.

The goal of software delivery is to minimize the lead time to business impact. Everything else is detail - Dan North

27 좋은 아키텍처는 시스템이 모노리틱 구조로 태어나서 단일 파일로 배포되더라도, 이후에는 독립적으로 배포 가능한 단위들의 집합으로 성장하고, 또 독립적인 서비스나 마이크로서비스 수준까지 성장할 수 있도록 만들어져야 한다. 또한 좋은 아키텍처라면 나중에 상황이 바뀌었을 때 이 진행 방향을 거꾸로 돌려 원래 형태인 모노리틱 구조로 되돌릴 수도 있어야 한다. - 로버트 C. 마틴(Robert C. Martin)의 저서 클린 아키텍처

• 28 유연한 시스템은 두가지가 필요
  - 혼돈에서 질서로 가는 모듈화: 경계를 쳐서 복잡성을 줄여줄 수 있는 도구인 모듈을 구성하고 협력시키는 것
  - 변경을 수용할 수 있는 소프트웨어 아키텍처: 관심사의 분리를 통해 애플리케이션 핵심(내부 - 도메인 영역)을 기술적인 부분(외부 - 인프라스트럭쳐 영역)과 분리시켜 외부에서 내부에 의존하는 단방향 의존관계 형성 및 외부는 관심사에 맞게 쉽게 변경 가능한 구조
• 계층 구조로 모듈화: 규모가 커지면 계층 내부의 복잡도가 증가 하므로 도메인을 기반으로 상위 경계를 만들고 내부를 계층의 구조로 만든다.
• 의존성 관리로 느슨하게 결합된 모듈 설계하기 (우아한 객체지향 참고)
• 전략적으로 시스템 통합을 돕는 컨텍스트 매핑
• 42 모듈사이 경계를 넘어오지 못하게 선긋기
• 적절한 가시성으로 모듈 보호하기
• 멀티프로젝트 구성을 통해 의존성 분리하기
• 모듈 자율성을 지켜주는 컨텍스트 경계 구성하기
• 컨텍스트 계층 구조로 모듈을 격리하기
• 컨텍스트 설정 모듈화
• 시스템 분리와 독립적인 서비스로 성장하기
• 소프트웨어 유지하는 동안 동작 시키게 만드는 게 아니라 더욱 유용하게 쓰이게 만드는게 목적 - 변경을 빠르게 수용, 비지니스를 최대한 빠르게 전달

software maintenance is not 'keep it working like before' It is 'keep it being useful in a changing world. - Jessica Keer, Atomist