인프런 커뮤니티 질문&답변
작성한 질문수
레이어간 흐름에 대한 엄격함
해결된 질문
작성
·
54
1
안녕하세요 제미니님, 유튜브부터 잘 보고 있는 수강생입니다. 항상 좋은 영상과 강의 감사합니다.
다름이 아니고 블로그에 작성해주신 글 [지속 성장 가능한 소프트웨어를 만들어가는 방법] 중 소프트웨어 레이어에 대해 언급을 해주셨는데, 해당 강의의 프로젝트가 이와 유사한 구조인 듯합니다.
질문:
제미니님은 현업에 계실 때에 비즈니스 레이어(Service)에서 도구 레이어(Finder, Handler,..)를 호출하는 흐름을 어느 정도까지 강제하셨는지가 궁금합니다.
팀 단위의 개발에선 컨벤션이 어느정도 정해져있는게 개발 생산성에 유리하지 않을까 하는 생각에 질문 남겨봅니다.
답변 미리 감사드립니다.🙇♂
답변 2
1
안녕하세요 질문 감사드립니다!
우선 가장 중요한걸 말씀해주셨는데요!
팀 단위의 개발에선 컨벤션이 어느정도 정해져있는게 개발 생산성에 유리하지 않을까
이건 무조건 맞다고 생각합니다 😃
다만 저는 어느 정도로 강제하였냐.......에서는 꽤나 복잡하고 고정 되어 있지 않습니다, 관련해서 유사한 질문이 있었어서 그 답변을 차용하여 답변드립니다!
사실 제 우선순위라 하면 가장 중요한 것이 회사/팀의 역량 수준이 들어가버립니다
그렇기 때문에 같이 일하는 동료들의 역량이 조금 아쉽다면, 약간의 경직 된 룰을 만들어서 팀을 유도합니다
물론 이 수준을 영원히 유지하지 않습니다 신입 팀원들이 어느정도 도메인에 익숙해지고, 구현에 익숙해진다면 좀 더 유연한 룰로 변경해나가는 것을 진행하는편입니다.
그래서 단순히 상황을 판단하긴 하지만 같이 일하는 동료를 기준으로 판단하는게 가장 큰 기준이 되는 것 같습니다
그렇다면 만약 베스트 팀이라면 제 경우는 소프트웨어가 성장하는 시점에 맞추어서 성장시키는 것을 선호하기 때문에 굳이 과하게 만드는 방향으론 개발을 하지 않습니다
(다만 제 커리어상으로도 회사에서 이렇게 할 수 있는 팀을 만난 것은 딱 한번 정도 같습니다 ;ㅁ; 현실적으로 어렵습니다......)
그래서 대부분 조금 타이트하게 통제된 정책을 만들고, 회사에서 사람이 바뀌거나 신입이 들어오더라도 적응하기 쉽고 작업하기 쉬우면서 품질을 직관적으로 볼 수 있는 형태를 더 선호합니다!
종합적으로 정리하면 회사/팀 수준과 일하는 상황을 느껴보고 판단하여 얼마나 강제할지 결정합니다 😃 (상황에 따라 매우 심하게 강제해본 적도, 엄청 느슨하게 해본 적도 있습니다 그리고 그 강도도 시간과 팀의 성장에 따라 유연하게 변경했던 기억이 있습니다)
모쪼록 답이 되었길 바랍니다! 감사합니다!
추가로 궁금한 것이 있으시면 질문 주시길 바랍니다! 😃
0
안녕하세요, 인프런 AI 인턴입니다. 철이와미애님.
소프트웨어 아키텍처에서 레이어 간의 흐름을 어떻게 정의하고 강제하는가는 클린 코드와 소프트웨어 유지 보수성 측면에서 중요한 문제입니다. 특히 팀 단위 개발에서는 이러한 흐름이 명확하고 통일되어야 개발의 효율성을 유지할 수 있습니다.
비즈니스 레이어와 도구 레이어 간의 흐름
비즈니스 레이어의 역할:
- 비즈니스 로직이 집중된 부분으로, 비즈니스 요구사항을 처리합니다. Service 클래스가 주로 이 레이어에 해당하며, 소프트웨어의 핵심 가치를 반영합니다.
- 비즈니스 로직이 집중된 부분으로, 비즈니스 요구사항을 처리합니다. Service 클래스가 주로 이 레이어에 해당하며, 소프트웨어의 핵심 가치를 반영합니다.
도구 레이어의 역할:
- 데이터베이스 통신, 외부 API 호출 등 비즈니스 로직을 지원하는 구체적인 구현이 이루어집니다. Finder, Handler 등으로 구분되며 비즈니스 레이어에서 필요한 기능을 제공합니다.
- 데이터베이스 통신, 외부 API 호출 등 비즈니스 로직을 지원하는 구체적인 구현이 이루어집니다. Finder, Handler 등으로 구분되며 비즈니스 레이어에서 필요한 기능을 제공합니다.
강제 및 권장 사항
레이어 간 호출 규칙 강제:
- 서비스 계층에서 도구 레이어를 호출하는 것이 일반적인 패턴입니다. 이는 비즈니스 로직이 도구적 구현 세부사항에 묶이거나 의존하지 않도록 하여 코드의 재사용성과 유지 보수성을 높입니다.
- 팀 내에서 어떠한 규칙을 강제했는가에 대해서는 보통 프로젝트 초기에 개발 규칙을 문서화하고, 코드 리뷰 프로세스를 통해 일관성을 유지합니다.
- 서비스 계층에서 도구 레이어를 호출하는 것이 일반적인 패턴입니다. 이는 비즈니스 로직이 도구적 구현 세부사항에 묶이거나 의존하지 않도록 하여 코드의 재사용성과 유지 보수성을 높입니다.
팀 컨벤션 설정:
- 프로젝트 초반에 팀원 간 컨벤션을 명확히 하고, 코드 리뷰를 통해 이를 지속적으로 확인합니다. 비즈니스 로직은 가능한 한 도메인 중심으로, 도구적 구현은 최대한 분리하여 관리합니다.
- 이러한 컨벤션은 개발 생산성을 높이는 데 큰 도움이 되며, 특히 새로운 팀원이 들어왔을 때 빠르게 프로젝트에 적응할 수 있게 해줍니다.
- 프로젝트 초반에 팀원 간 컨벤션을 명확히 하고, 코드 리뷰를 통해 이를 지속적으로 확인합니다. 비즈니스 로직은 가능한 한 도메인 중심으로, 도구적 구현은 최대한 분리하여 관리합니다.
관련해서 더 자세한 논의가 필요한 경우, 다음의 유사한 질문과 답변을 참조하시면 도움이 될 것입니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해 드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.