좋은, 나쁜 그리고 효과적인 설계
서서히 확산되는 문제 -> 설계되지 않는 것이 낮은 비용의 소프트웨어로 이어진다.
- 소프트웨어 개발을 이익 중심이 아닌 원가 중심으로 생각한다.
- 개발자가 모든 문제를 기술적으로 해결하려고 한다.
- DB에 너무 큰 우선순위를 둔다.
- 클래스와 오퍼레이션 이름을 짓는 것에 크게 관심이 없다.
- 프로젝트에 대한 예측을 매우 강하게 하여 지연되는 시간과 대비하여 예측한 기능을 사용하는 일이 오지 X
- slow query 로 인한 빠른 대응 불가능
- 강하게 결합된 서비스
5명의 개발자가 개발을 해야하는 프로젝트에서 설계없이 개발이 들어가게 되면..
- 5개의 서로 다른 설계가 하나로 뭉뜽그려진 것을 만들 뿐이다.
설계를 토대로 개발을 하는 것이 비용이 많이 들것이라는 생각이 든다면..
- 나쁜 설계를 수정해야 하는 비용에 대해 생각해보자.
효과적인 설계
- 좋은 것과 효과적인 것은 밀접한 관련이 있다.
- 효과적인 설계는 조직이 무엇에 강점을 가져야 하는지 이해시키고, 정확한 소프트웨어 모델을 생성하도록 가이드할 때 사용한다.
- 스크럼에서 지식 획득 은 실험과 협업 학습을 통해 이루어지며, 이를 정보 구입이라고도 한다.
- 지식은 절대로 공짜가 아니다.
- 단 한 가지 방안만을 추천하라면, 효과적인 설계를 추천하겠다.
대부분의 사람들은 '설계를 고민한다는 것'이 '어떻게 생긴 것인지 고민하는 것'으로 착각한다.
설계자에게 어떤 박스를 건네주고 "좋아보이게 만들어!"라는 이야기 정도로 생각한다.
이건 우리가 생각하는 설계가 아니다. 설계는 단지 어떻게 생겼는지, 어떤 느낌인지가 아니라,
그게 어떻게 동작하는지에 대한 것이다.
- 스티브잡스- 설계는 그게 어떻게 동작하는지에 대한 것이다.
전략적 설계
- 크게
- 세세한 구현으로 들어가기에 앞서 두꺼운 붓 터치처럼 사용하며, 비즈니스상 전략적으로 중요한 것, 중요도에 따라 일을 나누는 방법, 그리고 필요에 따라 통합하는 최적의 방법을 강조
- 키워드 : 바운디드 컨텍스트(도메인 분리), 보편언어, 서브도메인, 컨텍스트매핑(통합)
전술적 설계
- 세세하게
- 도메인 모델의 세부사항들을 그리기 위해 얇은 붓을 사용하는 것과 같다.
- 키워드 : 애그리게잇 패턴
학습 과정과 지식의 정제
- DDD는 지식을 더욱 발전시킬 수 있도록 나와 팀에게 생각하는 법을 알려준다.
- 질문, 이의제기, 지식회득, 공유
공부기록
백엔드 개발자