최근 이직을 하고 레거시 시스템을 개선하는 작업을 하기위해 준비하다보니 문득 든 생각이 있습니다.
기획서도 몇십번 보고, 사이트 사용도 다 해보고, 코드도 여러번 봤지만…
그래서 이 시스템이 추구하는 업무 프로세스 (도메인) 은 어떤 형태로 나타내야하는걸까?
혹은 어떻게 표현해야 빠지지않고 도메인 전문가가 달성하려고 하는 사업목표에 대해서 의도한대로 시스템을 구성하지?
라는 생각이 드네요.
요런건 어떻게 배울수 있을까요?
1 Like
"소프트웨어 디자인을 어떻게 할 것인가"에 관한 질문인 것 같습니다.
Beginning C# Object-Oriented Programming (bedford-computing.co.uk)
링크된 책의 1 ~ 4장까지의 내용이 도움이 되실 것 같습니다.
그 이후의 장은 올드하기도 하고, 개발자라면 거의 모두 아실만한 내용입니다.
이 책의 초반부에 아래와 같은 얘기가 나옵니다.
A good analogy to software design is the process of building a home. You would not expect a builder to start
working on the house without detailed plans (blueprints) supplied by an architect. You would expect the architect to
discuss the home’s design with you before creating any blueprints. It is the architect’s job to listen to your requests and
convert them into plans that a builder can use to build the home. A good architect will also educate you as to which
features are reasonable for your budget and projected timeline
소프트웨어를 설계하는 것은 집을 짓는 과정과 다름이 없다.
집을 지을 때 설계사의 청사진 없이 시공을 개시하는 것을 상상하기는 힘들다. 보통은 설계사와 집주인인 당신이 충분한 상의를 한 후, 청사진을 도출하(고 청사진 대로 시공하)는 것이 일반적인 절차이다.
당신의 요구 사항을 청취한 후에, 이를 집을 짓는 과정(청사진)으로 변환하는 것이 설계사의 업무이다. 좋은 설계사라면 여기에 더해 허락된 예산과 시간에 따라 집이 어떻게 달라지는 지를 알려 주기도 한다.
결론은 “소비자와 함께 설계하라”… 아닐까요? ^^
이 책은 소비자의 요구사항을 객체 지향 소프트웨어에 반영하는 과정을 설명합니다.
그 과정에 SRS, UseCase 등의 개념 등이 등장합니다.
5 Likes
감사합니다!
1 Like