Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

3.19 아키텍처 결정 #36

Open
SeokRae opened this issue Apr 12, 2022 · 1 comment · Fixed by #37
Open

3.19 아키텍처 결정 #36

SeokRae opened this issue Apr 12, 2022 · 1 comment · Fixed by #37

Comments

@SeokRae
Copy link
Member

SeokRae commented Apr 12, 2022

  1. '네 패를 먼저 보여주지마' 안티 패턴은 무엇인가?
  2. 이메일 기반 아키텍처 안티패턴을 방지하려면 어떻게 해야하는지?
  3. 마이클 나이가드는 아키텍처적으로 중요한 뭔가를 식별하는데 필요한 다섯가지 팩터를 어떻게 정의하는지?
  4. 아키텍처 결정 기록(ADR)의 5대 기본 섹션은 무엇인가?
  5. 아키텍처 결정의 정당화는 보통 ADR 어느 섹션에 추가하나?
  6. 대안 섹션이 따로 필요없는 경우, 여러분이 제안한 솔루션의 대안은 ADR의 어느섹션에 열거하는지?
  7. ADR 상태를 제안됨(Proposed)으로 표시하는 세 가지 기본적인 기준은 무엇인가?
@SeokRae SeokRae self-assigned this Apr 15, 2022
@SeokRae SeokRae linked a pull request Apr 17, 2022 that will close this issue
@SeokRae SeokRae reopened this Apr 24, 2022
@SeokRae
Copy link
Member Author

SeokRae commented Apr 24, 2022

  • '네 패를 먼저 보여주지마' 안티 패턴은 무엇인가?

아키텍트가 잘못된 선택을 하는 것을 두려워한 나머지 아키텍처 결정을 회피하거나 미루는 현상
이는 두 가지 방법으로 극복이 가능하다.

  1. 어떤 중요한 아키텍처 결정을 내리기 전, 마지막으로 책임질 수 있는 순간까지 기다리는 것
  2. 개발팀과 지속적으로 협력하면서 아키텍트가 결정한 내용을 원래 의도한 대로 추진하기
  • 이메일 기반 아키텍처 안티패턴을 방지하려면 어떻게 해야하는지?

이는 의사결정된 내용이 적절하게 공유되지 않아서 생긴 문제로

  1. 이메일 본문에 아키텍처 결정을 포함하지 말고 본질과 맥락 정도만 언급하고 세부 정보는 단일 기록 시스템에 보관하여 링크로 제공하기
  2. 아키텍처 결정에 정말 관심있는 사람들에게만 통지하기
  • "안녕하세요. XX님, 다름아니라 부서에 직접적으로 영향을 미치는 서비스 간 통신에 관한 중요한 결정을 내렸으니 아래 링크를 통해 확인 부탁드립니다"
  • 마이클 나이가드는 아키텍처적으로 중요한 뭔가를 식별하는데 필요한 다섯가지 팩터를 어떻게 정의하는지?

아키텍처 적으로 중요한 결정이란 구조, 비기능 특성, 의존성, 인터페이스, 구현 기술에 영향을 미치는 결정이라 볼 수 있다.

  • 구조
    • 사용중 인 아키텍처의 패턴이나 스타일에 영향을 미치는 결정들
  • 비기능 특성
    • 개발 또는 유지보수 중인 애플리케이션이나 시스템에 중요한 아키텍처특성(∼성)들
  • 의존성
    • 전쳬확장성, 모듈성, 민첩성, 시험성, 안정성 등에 영향을 미치는 시스템 내부의 컴포넌트와(또는) 서비스 간의 커플링 지점을 가리킨다.
  • 인터페이스
    • 게이트웨이, 통합 허브, 서비스 버스, API 프록시를 통해 서비스와 컴포넌트에 액세스하고 조정하는 수단을 말한다.
  • 구현기술
    • 원래 그 자쳬는 기술적인 것이지만, 아키텍처의 많은 부분에 영향을 미치는 플랫폼, 프레임워크, 도구, 프로세스에 관한 결정
  • 아키텍처 결정 기록(ADR)의 5대 기본 섹션은 무엇인가?
  • 제목
    • 아키텍처 결정을 짤막한 문구로 표현
  • 상태
    • 제안됨, 수락됨, 대체됨으로 표시
  • 컨텍스트
    • 불가항력적인 요소를 특정한다.
  • 결정
    • 아키텍처 결정과 그렇게 결정하게 된 사유를 밝힌다.
  • 결과
    • 아키텍처 결정의 전체적인 영향도를 기술한다.
  • 아키텍처 결정의 정당화는 보통 ADR 어느 섹션에 추가하나?
  • 대안 섹션이 따로 필요없는 경우, 여러분이 제안한 솔루션의 대안은 ADR의 어느섹션에 열거하는지?
  • ADR 상태를 제안됨(Proposed)으로 표시하는 세 가지 기본적인 기준은 무엇인가?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant