절차와 도구보다는 개성과 화합을
방대한 문서 작업보다는 동작하는 소프트웨어를
계약 조건에 대한 협상보다는 고객과의 협력을
계획을 따르는 것을 넘어서서 변화에 대처하는 것을
아름다운 코드는 지저분한 코드보다 낫다.
명확한 코드는 암시적인 코드보다 낫다.
단순한 코드가 복잡한 코드보다 낫다.
복잡한 코드가 난해한 코드보다 낫다.
단조로운 코드가 복잡한 코드보다 낫다.
읽기 쉬운 코드는 읽기 어려운 코드보다 낫다.
The goal of software architecture is to minimize the human resources required to build and maintain the required system.
― Robert C. Martin, Clean Architecture
소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화 하는데 있다.
가장 작은 코드 레벨에서의 설계원칙: SOLID
조금 더 큰 덩어리의 클래스와 모듈들을 어떻게 묶을 것인가에 대한 이야기
반대로 어떤 놈들을 하나로 묶을 것인가?
가장 작은 단위에서 SOLID를 보고 컴포넌트에 대해서 REP, CCP, CRP를 보았으니 이제는 컴포넌트들 끼리의 결합 원칙을 본다.
시스템의 아키텍처를 짠다는 것은
아키텍처를 잘 짜면
정책은 시스템의 가장 핵심적인 요소이다.
세부사항은 정책과 무관하게 만들 수 있다. 만드는 게 좋다.
의존성은 안쪽을 향한다.
바깥쪽의 데이터 형식을(DTO) 내부원에서 사용하지 않는다.
GitHub(private): https://github.com/nicewook/mongo-golang
마무리하며 아직 낯서신 분들은 클린 아키텍처랑 처음 얼굴 익힌 시간이라 생각해주셨으면 합니다.
돌아가며 한 말씀씩만 부탁드립니다 좋았던 것, 이해 안되었던 것, 그 다음 궁금한 것 그리고 기분 점수
1. 생산성: 적은 인원으로 많은 일을 한다 2. 커뮤니케이션 비용: 혼자 개발 다하면 커뮤니케이션 비용 ZERO