heoh***
2021-06-21

개발자에서 아키텍트로, 변화의 첫걸음을 내딛는 이를 위한 실전 입문서다. 설계를 위한 필수 지식, 아키텍처 패턴, 모델, 설계 방법론, 커뮤니케이션 노하우를 상세히 소개한다. 문제 상황에서 팀원들과 해볼 수 있는 38가지 팀 활동을 소개하며 실무 적응 능력을 키워준다.
PART1 소프트웨어 아키텍처
CHAPTER 1. 소프트웨어 아키텍트란 무엇이며, 소프트웨어 아키텍트가 하는 일에 대해서 설명합니다.
소프트웨어 아키텍트는 팀에서 독특한 위치에 있습니다.
아키텍트는 소프트웨어가 언제 어떻게 전달되는지 결정하는 사람입니다.
또한 소프트웨어가 비즈니스 목표에 부합하도록 만드는 사람입니다. 코딩은 하지만 알고리즘이나 코드를 짜기보다는 더 크고 많은 것을 설계합니다.
CHAPTER 2. 디자인싱킹은 소프트웨어를 개발하는 데서 기술과 사람을 잇는 방법을 알려줍니다.
PART2 아키텍처 설계의 기초
CHAPTER 3. 설계 전략 고안하기에서는 아키텍처를 설계할 때 디자인 마인드셋을 적용하고 생각-실행-확인 사이클을 거치면서 어떤 부분에 초점을 맞춰야 할지 배웁니다.
CHAPTER 4. 이해관계자와 공감하기 - 이해관계자란 어떤 소프트웨어에 관심이 있거나 관여된 사람을 일컫습니다. 이해관계자가 누구인지 알아내고 그들의 요구를 이해하는 일이 아키텍트의 역할이기도 합니다.
CHAPTER 5. 아키텍처 핵심 요구사항 알아내기 - 챕터4에서는 이해관계자를 중심에 두고 누가 소프트웨어에 영향을 미치고 왜 우리가 그들을 중요하게 생각해야 하는지 알아봤습니다. 이번 장은 소프트웨어 아키텍처 관점에서 '무엇을'에 해당하는 요구사항을 알아봅니다.
CHAPTER 6. 아키텍처 선택하기 - 이번 장에서는 핵심 요구사항을 이용해 구조를 어떻게 선택하고 의사결정을 해나가는지에 대해 알아봅니다.
CHAPTER 7. 패턴으로 기초 만들기 - 어떤 소프트웨어 시스템이든 작은 주제의 패턴을 모아놓고, 그 위에서 전체 디자인을 결정합니다. 패턴을 사용하면 팀원들에게 소프트웨어 아키텍처를 설득하기 편해집니다. 패턴을 사용하면 수고스러운 노력을 직접 기울이지 않고도 다른 사람들의 지혜를 얻을 수 있습니다. 이 번 장에서는 가장 자주 사용하는 패턴 몇 가지를 알아보고, 이를 요구사항에 어떻게 적용하는지 소개합니다.
CHAPTER 8. 의미 있는 모델로 복잡도 관리하기 - 소프트웨어 복잡도가 점차 증가할때 쯤에는 몇가지 선택지가 있습니다. 요구사항을 수정하거나 코드의 일정 부분을 덜어내서 다시 소프트웨어를 좀 더 작게 만들 수 있습니다. 이번 장에서는 여러 요소를 쌓아올리면서 의미 있는 모델을 만드는 방법과 이를 통해 더 수월하게 아키텍처를 파악하는 방법에 대해 알아봅니다.
CHAPTER 9. 아키텍처 디자인 스튜디오 운영하기 - 이 장에서는 아키텍처 디자인 스튜디오를 계획하고 운영하는 방법에 대해 알아봅니다. 먼저 디자인 스튜디오의 개요부터 짚어본 후, 디자인 스튜디오를 쉽게 꾸리는 방법을 배울 것입니다.
CHAPTER 10. 설계 시각화 하기 - 챕터 10에서는 아키텍처 다이어그램을 그리는 방법을 배우고 개발들과 수월하게 대화하는 방법에 대해서 알아봅니다.
CHAPTER 11. 아키텍처 문서화 하기 - 훌륭한 문서는 업무 계획의 근간이 되며, 커뮤니케이션 보충 자료이자 협업 도구이기도 합니다. 설계 의사 결정을 할때 모두에게 공통의 인식을 심어주어서 더 나은 품질의 소프트웨어를 만들 수 있게 합니다.
CHAPTER 12. 아키텍처 평가하기 - 이 장에서는 아키텍처에 성적표를 부여하는 방법에 대해서 알아봅니다. 평가의 피드백은 팀을 교육하고, 설계 시 의사결정을 보강하고, 배포의 위험을 줄이고, 아키텍처를 개선하는 데 사용 할 수 있습니다.
CHAPTER 13. 아키텍트에게 힘 실어주기 - 이 번 장에서는 멋진 소프트웨어 아키텍처를 함께 설계하면서 팀을 성장시키고 역량을 강화하는 방법을 배웁니다.
PART 3. 아키텍트의 은색 도구상자
CHAPTER 14. 문제를 이해하고 싶을 때 - 문제 해결을 위한 공감대가 형성되면 이해관계자들에게 적극적으로 정보를 수집하고 문제를 정의해갑니다. 공감대를 형성한다는 건 요구사항을 정의하는 것보다 한 단계 더 높은 차원의 일입니다. 이해 관계자가 누군지 알
아내고, 시스템의 비즈니스 목표를 확인하고, 아키텍처의 특성에 맞추어 요구사항을 파악합니다.
CHAPTER 15. 해결책을 찾고 싶을때 - 이 장에서 소개하는 활동은 아키텍처를 설계하며 여러 대안을 만들 때 유용합니다. 아키텍처로 발전할 수 있는 구조를 탐색하고, 실제로 구현해낼 엔지니어링 접근법을 찾아낼 수 있습니다.
CHAPTER 16. 손에 잡히는 설계를 만들고 싶을때 - 이 장에서 다루는 활동들의 결과물은 아키텍처를 실물로 만드는데 큰 도움이 될 것입니다. 결과물은 혼자서 직접 만들 수 있지만, 때로는 다른 사람과 짝을 지어 하거나 큰 그룹으로 협업할때 더 재미있고 유익할 수 있습니다.
CHAPTER 17. 설계 대안을 평가하고 싶을때 - 이 장에서 소개하는 활동은 팀원들과 아키텍처의 다양한 측면을 살펴보고 정보를 모아서 적절한 조치를 취하고자 할때 유용합니다. 아키텍처를 얼마나 잘 이해했는지 확인하거나, 설계의 대안을 선택하거나, 다음에 수행할 작업을 결정해야 할 때 활용하면 좋습니다.
끝으로
소프트웨어 아키텍처는 멋진 소프트웨어를 만드는 단단한 기반입니다. 훌륭한 아키텍처가 소프트웨어 성공을 보장하지는 않지만 최소한 실패의 가능성을 적게 만들어줄 것입니다. 소프트웨어 개발자라면 소프트웨어 아키텍처에 대해 꼭 알아야 합니다. 이 책에서 훌륭한 소프트웨어 아키텍처를 어떻게 설계하는지 배우게 될 것입니다.
이 책으로 설계자다운 사고방식과 인간중심적인 접근 방법을 배울수 있을 뿐만 아니라 팀원 간에 협업하면서 소포트웨어를 설계하는 방법도 배울 수 있습니다. 소프트웨어 아키텍처라면 이 책을 통하여 기술과 현실을 효과적으로 배우게 될것입니다.