설계

6.1 아키텍처 특성 측정 아키텍처 특성을 정의할 때 흔히 다음과 같은 문제들이 발생한다. 물리학이 아니다 : 아키텍처 특성은 대부분 의미가 모호하다. 정의가 너무 다양하다 : 부서마다 정의를 통일하기 전까지는 원활한 소통이 어렵다. 너무 복합적이다 : 바람직한 아키텍처 특성은 대부분 더 작은 다른 여러 특성들로 구성된다. 이 세가지 문제들은 아키텍처 특성을 객관적으로 정의하면 모두 해결된다. 6.1.1 운영적 특성 아키텍처 특성은 성능, 확장성처럼 비교적 정확하게 측정할 수 있는 것도 많지만, 팀 목표에 따라 그에 따른 해석은 미묘하게 갈릴 때가 많다. 예를 들어 특정 요청에 대한 평균 응답 시간을 측정할 경우, 어떤 경계 조건 때문에 1%의 요청이 다른 요청보다 처리 시간이 10배 오래 걸리면 어떻게..

4. 아키텍처 특성 정의 아키텍트는 개발팀과 함께 도메인 또는 비즈니스 요구사항을 정의할 수 있지만, 주로 소프트웨어로 처리할 일 중 도메인 기능과 직접적인 관련이 없는 모든 것들, 즉 아키텍처 특성(architectural characteristic)을 정의, 발견, 분석하는 일을 수행한다. 아키텍처 특성은 다음 세 가지 기준을 충족한다. 비도메인(nondomain) 설계 고려 사항을 명시한다. 어플리케이션 설계 시 어플리케이션으로 처리할 일은 구체적인 요구사항으로 정리한다. 아키텍처 특성은 이 요구사항을 구현하는 방법, 어떤 선택을 하게 된 이유와 관련된 운영/설계 기준을 명시한다. e.g. 일반적으로 어느 정도의 어플리케이션의 성능은 중요한 아키텍처 특성이지만, 요구사항 정의서에는 적혀있지 않는 경..

플랫폼마다 제공하는 코드 재사용 메커니즘은 제각각이지만, 연관된 코드를 모듈(module)로 묶는 방법은 모두 지원한다. 본인이 선택한 개발 플랫폼에서 모듈성과 그것을 구현한 수 많은 코드를 이해하는 것은 아키텍트에게 대단히 중요한 일이다. 우리가 아키텍처를 분석해야 할 (메트릭, 피트니스 함수, 시각화 등) 많은 도구가 이 모듈성에 기반하기 때문이다. 모듈성은 일종의 구성 원리(organizing principle)이다. 아키텍트가 대충 아무렇게나 조각들을 이어 붙여 시스템을 설계하면 무수한 난관에 봉착해 옴짝달싹 못 하는 시스템이 되어 버린다. 물리학에 비유 하자면, 소프트웨어 시스템은 엔트로피(entropy, 무질서)가 증가하는 방향으로 움직이는 복잡한 시스템을 모델링한다. 질서를 유지하려면 물리적..

아키텍처의 사고는 크게 네 가지로 나뉜다. 아키텍처와 설계의 차이를 이해하고 아키텍처 작업을 진행하면 개발팀과 어떻게 협력해야 할지 아는 것 어느 정도 기술의 깊이를 유지하면서 폭넓은 기술 지식을 확보하는 것 아키텍트는 다른 사람들이 보지 못하는 해결책과 가능성을 떠올릴 수 있다. 다양한 솔루션과 기술 간의 트레이드오프를 이해하고, 분석하고 조율하는 것 비즈니스 동인(business driver)의 중요성을 이해하고 그것을 아키텍처 관심사로 해석할 줄 아는 것 2.1 아키텍처 대 설계 아키텍트처럼 사고한다는 건 비즈니스와 기술 문제를 해결하기 위해 아키텍처와 설계의 차이점을 알고 이 둘을 긴밀하게 통합한 솔루션을 모색하는 것이다. 전통적인 아키텍트의 책임과 개발자의 책임은 다음과 같다. 이 전통적인 아키..

을 읽고 챕터별로 주요한 내용들을 간략하게 정리해 보려고 한다. Ch01. 서론 10년 전만 해도 소프트웨어 아키텍트는 주로 모듈성(modularity), 컴포넌트(component), 패턴(pattern) 등 순수 기술적인 부분을 다루었지만, 이제는 (마이크로서비스처럼) 훨씬 폭 넓은 능력을 활용하는 새로운 아키텍처 스타일의 등장으로 인해 그 역할과 범위가 한층 더 확대되었다. p26 1.1 소프트웨어 아키텍처란? 소프트웨어 아키텍트는 이렇게 끊임없이 변하는 생태계 안에서 뭔가 결정을 내리는 사람들이다. 아키텍처를 공부하는 사람들이 명심해야 할 점은, 아키텍처란 예술과 마찬가지로 콘텍스트(context, 문맥, 맥락)로서만 이해할 수 있다는 것이다. 20세기의 아키텍처의 주요 목표 중 하나는 최대한 효..

1. 실용주의 철학 1. 고양이가 내 소스코드를 삼켰어요 가장 큰 약점은 약점을 보일 것에 대한 두려움이다. - 보쉬에 1709 실용주의 철학의 초석 중 하나는 경력 향상, 프로젝트, 일상 업무의 면에서 자신과 자신의 행동에 책임을 지는 것이다. 실용주의 프로그래머는 경력에 대해 책임을 지고, 자신의 무지나 실수를 인정하기를 두려워 하지 않는다. 만약 벤더가 끝까지 잘 해내지 못할 위험요소가 있다면 여러분이 그에 대한 대책(contingency plan)을 세워야 한다. 소스코드와 디스크가 다 망가져 버렸는데 백업이 없다면, 그것은 여러분의 잘못이다. 라고 상관에게 말하는 것은 별 도움이 안 될 것이다. Tip 어설픈 변명을 만들지 말고 대안을 제시하라 p32 나쁜 소식을 전하러 가기 전에 뭔가 시도해 ..

해당 포스팅은 프로그래밍 인사이트에서 출판한 (이브 포셀로, 알렉스 뱅크스 저)을 바탕으로 작성한 글임을 먼저 밝힙니다. GraphQL이란? 클라이언트의 종류가 다양해지고 복잡해지면서 서버로부터 데이터를 받아와서 빠르고 손실없이 클라이언트에 전송하는 기술은 끊임없이 발전해 왔고 현재도 진행 중에 있다. GraphQL은 이 과정에서 만들어진 쿼리 언어이다. GraphQL 쿼리는 실제로 필요한 데이터만 받도록 작성할 수 있다. 응답은 JSON 형태로 주어진다. 쿼리문을 중첩하여 실행하면 연관된 객체를 응답 데이터로 같이 받을 수도 있다. GraphQL 서버에서는 쿼리가 실행될 때마다 타입 시스템에 기초해 쿼리가 유효한지 검사한다. GraphQL 서비스를 만드려면 GraphQL 스키마에서 사용할 타입을 정의해..

요즘에 실무에서 프론트엔드 개발을 하기 시작하면서, 과거에 혼자서 프로젝트를 할 때와 다른 점들이 몇 가지가 보이기 시작했다. 그 중에 하나가 디자인 패턴인데, 아직도 나는 디자인 패턴을 왜 써야 하고 또 잘 쓰려면 어떻게 써야 하는지에 대해서 잘 모른다. 그래서 주말에 조금씩 디자인 패턴을 공부해 보기로 했다. 교재는 이고 디자인 패턴 관련된 책 중에서 오랫동안 많은 사람들한테 읽혀진 책 중 하나이다. 책의 내용을 정리하면서, 최근에 추가되거나 수정된 내용들을 적절하게 업데이트 하는 식으로 공부 및 포스팅을 작성해 보려고 한다. 개발자들은 혼자서 프로젝트를 하는 경우보다 여럿이 함께 하는 경우가 훨씬 더 많다. 그리고 혼자 하더라도 그 사람이 처음부터 끝까지 프로젝트를 책임지고 한다는 보장은 없다. 그..