안녕하세요 여러분!
오늘은 비즈니스 로직과 관련한 영상을 보고 느낀점을 말해보려 해요.
아래 인프런 강의를 듣고 느낀점이 많습니다.
제미니의 개발실무 - 지속 성장 가능한 소프트웨어를 만들어가는 방법
지금까지 제가 만들었던, 구현했던 방법들은 전혀 객체스럽지 못했고 구현하는데에 동작하는데에만 집중했다고 느껴집니다.
기존에 제가 작성한 방식
저는 소프트웨어를 지속가능한, 오래 유지될 수 있는 방법들을 고민하지 않고 기능이 동작하는데에만 집중을 했었어요.
어떻게 확장해 나갈지, 혹은 변경사항이 발생하였을때 어떻게 대처할지에 대한 고민들은 하지 못했죠.
위 사진에 보이는것 처럼 저는
Layer는 3개로 Controller, Service, Repository 로 나누고 각 Layer에 역할에 맞게 구현해보자.
라고 생각하였고
Business Logic 은 Service 에 구현 해야지!
라고 생각하였어요. 예를 들어 게시글을 작성하는 기능이라면 PostService에서 데이터에 대한 검증, 탐색, 저장을 모두 진행하는 것이죠. PostService는 서비스 로직과 연관된 모든 Repository 들을 모두 생성자 주입을 받으면서 결합도를 높이고 있었어요.
이러한 작성방법은 좋지 않은 방법이라고 할 수 있어요.
안좋은 예시.
이와같은 방법은 비즈니스 로직이라기 보다는 상세한 구현 로직에 가깝다고 할 수 있어요.
그러면 이러한 내용들을 어떻게 리팩터링할 수 있을까요 ?
지속 가능한 설계의 좋은 방향성
위와 같이 리팩토링을 할 수 있을 것 같아요.
비즈니스 로직이란 대략적으로 로직들의 흐름이 보이도록 작성하는것이 비즈니스 로직이라고 할 수 있어요.
실제 데이터를 찾아오고, 객체를 생성하고 등등 이러한 것들은 비즈니스 로직이라기 보다는 구현에 가까운 것이죠.
강의를 듣고는
각 역할과 책임들을 객체별로 나누어 쪼개고
각 객체들의 하는 역할들의 흐름을 제어하는 곳이 비즈니스 로직이라고 생각이 들었어요.
강사님의 말을 직역해보면
비즈니스 로직은 비즈니스 흐름 기준으로 각 역할을 가진 협력도구 클래스들을 중개해주는 역할만 하고 있으며, 각 도구 클래스들이 명시적으로 한 가지의 일을 하고 있는 형태가 잘 나타난걸 볼 수 있습니다.
비즈니스 로직이라 하면 비즈니스를 하는 사람들은 다 이해할 수 있어야 될 거거든요.
그런 관점에서 이런 비즈니스 로직을 짜 간다고 이해해 주시면 좋을 것 같습니다.
레이어 같은 경우는 위와 같이 가져가면서 각 레이어들간의 규칙은 아래와 같이 정의를 해보면 좋다고 해요.
- 레이어는 위에서 아래로 순방향으로만 참조 되어야 한다.
- Data Access Layer(Repository) 에서 Presentation Layer(Controller) 를 참조하면 안된다.
- 레이어의 참조 방향이 역류되지 않아야 한다.
- 위와 동일한 내용입니다.
- 레이어의 참조가 하위 레이어를 건너 뛰지 않아야 한다.
- 제가 기존에 작성한 것 처럼, Business Layer가 Data Access Layer를 직접 참조하면 안됩니다.
- 동일 레이어 간에는 서로 참조하지 않아야 한다.
- 다만 Implement Layer는 제외
저에게 위의 내용들은 정말 모두 하나같이 와닿았었고, 주옥같은 내용들이었어요.
어렴풋이 이렇게 하는게 맞을까? 하는 내용들을 명확하게 짚어주셔서 좋은 설계에 대해 조금이나마 이해할 수 있었습니다.
좋은 소프트웨어를 위한 노력
아래부터는 현재 진행하고 있는 서비스에 위의 개념들을 적용해보기 위한 노력들로 Github Issue들을 통해 고쳐나가보려 합니다.
아래 내용은 주기적으로 업데이트 될 예정입니다.
5/10
