1. 설계 시각화 필요성
설계의 결과물을 작성하는 방법을 전공수업에서 얼핏 들었던 기억이 있다.
당시에는 구현 기술을 배우는 것이 더 재미있어서 이러한 소프트웨어 공학과 같은 이론 수업에는 흥미가 없어 단지 수업을 위한 공부만 진행하고, 언어를 배우는 실습 수업 위주로 집중해서 공부를 했었다.
여러가지 개발 프로젝트를 진횅해보면서 설계 시각화의 필요성을 체감하게 되었다.
개발 프로젝트는 혼자서 하는 것이 아니라 다양한 관점을 가진 여러사람이 힘을 합쳐 진행을 하게 된다.
여기서 아이디어가 나오고 바로 구현에 들어가게 되었을 때, 분명 이전에 말과 생각을 모두 하나로 맞췄다고 생각을 했지만, 결과물은 산으로 가고 있었다.
모두가 나와 같은 생각을 하고 있다는 것은 착각에 불가했다.
이를 해결하려 다시 회의를 하고, 수정하고 일을 2번하는 상황을 자주 마주했었다.
여기서 개발 목표와 구현 방식을 시각화하여 생각을 통일하는 과정의 필요성을 느꼈다.
모두가 이해할 수 있는 방식으로 개발 목표와 구현 방식을 그려 설계도를 완성하고, 완성된 것을 기반으로 개발을 진행한다면 시행착오를 줄일 수 있다.
규모가 큰 프로젝트일수록 다양한 배경을 가진 이해관계자들이 프로젝트에 참여를 하게 될 것이고, 프로젝트의 복잡도는 훨씬 높을 것이기에 말로만 의견을 맞추고 프로젝트를 진행한다는 것은 불가능에 가까울 것이다.
아니, 진행 자체가 안될 것이다. (수많은 태클이 들어올 것이기에...)
그래서 모두가 이해할 수 있고, 표준화된 설계 방식이 필요하다.
설계의 필요성
1. 요구사항을 가장 효율적으로 만족
2. 유지보수 측면에서 압도적으로 편함
3. 협업에서 이점 << 가장 중요하다고 생각한다.
2. 객체지향 설계
객체지향을 생각하면서 설계를 하려면, 역할과 구현을 확실하게 구분지어 생각해야한다.
비즈니스 요구사항
회원
- 회원을 가입하고 조회할 수 있다.
- 회원은 일반과 VIP 두 가지 등급이 있다.
- 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정)
1. 클래스 다이어그램
2. 객체 다이어그램
3. 이해하기 쉬운 설계
이 설계 방식은 개발자가 아닌 프로젝트 참여자 모두가 이해할 수 있는 설계도라고 설명을 들었다.
프로젝트마다 약속된 방식이 다르겠지만, 다이어그램을 그리기 전에 머릿속으로 그리면 많은 도움이 될 것 같아서 남겨본다.
1. 도메인 협력 관계
