[java,Spring] 강한 결합과 약한 결합.. (뚱뚱한 Service, Controller에 대한 회고)

<obsidian에서 작성중>

시작하기 전에…

 최근 '개발자로써 내가 지닌 역량과 그 한계’에 대한 고민이 들어 멘토님께을 상담을 요청드렸고, "개인은 본인보다 더 나은 사람과 본인을 비교하기 마련이다. 개발은 꾸준함이며, 굳이 비교를 하려면 과거의 본인과 비교를 해야지 타인과 비교를 하는 순간 컨트롤 할 수 없고 끊임이 없는 회의감에 마주하기 쉽다"는 답변을 받았다.
 그러던 와중 JAVA의 객체지향에 관한 팀스터디를 진행하며 리더가 되어 팀원들에게 내 여러 프로젝트의 코드들을 예시로 보여주며 설명할 기회가 있었다. '이렇게 하면 안된다’고 설명하고 싶을 때 나의 첫 프로젝트는 아주 좋은 표본이 되었고, '이런점들 때문에 최근에는 이렇게 하는 추세이다’라며 개선된 코드의 표본을 보여주고 싶었을 때 최근의 프로젝트들은 좋은 표본이 되었다. 이에 내 성장을 기록하고 회고하여 “보다 객체지향적이고 유지보수 하기 좋은 코드를 짜는 개발자”가 되었으면 하는 마음에 이번 글을 작성하고자 한다.

이번 학습을 통해 기대하는 학습 효과

1. 강한 결합과 약한(느슨한)결합에 대한 개념을 정리
2. 강합 결합을 배제해야 하는 이유에 대해서 정리하고, 그럼에도 불구하고 강한 결합이 필요한 경우가 있을지 고민해보기
3. 내 과거의 결합도 높은 코드들과, 현재의 비교적 개선된 코드들을 비교하고, 앞으로 어떠한 부분을 신경쓰며 개발해야할지 회고하는 시간을 가져보고자 함.
   
   

강합 결합

약한 결합(Loose Coupling, 느슨한 결합)

강한 결합을 배제하는 이유

약한 결합보다 강한 결합을 사용해야하는 때도 있을까?

DDD의 주요 설계 원칙: Loose Coupling(느슨한 결합)과 High Cohesion(높은 응집)

DDD에서 도메인들 간에는 Loose Coupling하고 도메인 내에서는 High Cohesion 해야 한다.

뚱뚱한 Service, Controller에 대한 회고

1) 초초초보 개발자 시절 Yana의 Controller, Service를 살펴보자 (feat 첫 팀프로젝트)

2) 초초보 개발자 시절 Yana의 Controller, Service를 살펴보자 (feat n회차 팀프로젝트)

몇 차례 프로젝트를 거치면서 코드의 재사용을 위해 점차적으로 비교적 약한 결합으로 변해가고있지만, 아직도 많이 부족하다…

3) (현)초보 개발자 Yana의 Controller, Service를 살펴보자

추후 학습 방향

Test 코드를 짜게되면서 바뀌게되는 방향을 알아보자 희희