- 기존의 모델에서는 Users, Company 두 유저 도메인이 존재했는데, 인증과 인가 구현 코드의 대부분이 중복되고 있었기 때문에 두 도메인을 분리했던 것을 통합하는 방법을 고민해보았다. 회사 채용 공고 등록, 삭제 및 수정에 대한 권한을 어떻게 부여할 것인가에 대한 점을 고려해야 했으며, 유저와 회사 유저에 대한 user role를 어떻게 분할해야 할지가 관건이었다.
- 결국 Users 하나의 도메인만을 사용하면서, 각 회사의 채용 당담자들의 정보를 담는 Recruiters 테이블을 새로 추가하여 user에 role을 추가하는 방식으로 확장해보았다.
- 이는 중복되는 인증과 권한에 대한 부분을 간결하게 할 수 있고, 채용 공고 도메인에 대한 권한을 recruiters의 company_id와 recruiter_id 값을 이용해 인증 절차 구현을 할 수 있을 것으로 기대한다. 또한 이는 해당 공고를 작성한 채용 담당자를 식별할 수 있는 기능으로도 확장될 수 있다.
- 채용 담당자의 정보를 담는 recruiters이다. fk값으로 user_id와 compay_id를 갖는다.
- 유저 도메인으로 통합했지만, recruiters 권한 등록은 어떻게 해야 할까? 이는 추후 Company 모델에 필요한 채용 담당자 등록을 위한 인증 키 보안값 등을 추가하여. 이 인증값을 통해 해당 회사의 채용 담당자 등록을 한 후 recruiters 모델에 추가될 수 있지 않을까 싶다.
- 일반 유저와 또다른 유저로 분리되었던 회사 모델을 간단히 회사에 대한 정보만을 담을 수 있는 도메인으로 변경을 하였다.
- 이전에는 Company 유저라면 해당 공고에 대한 수정/삭제 기능 role을 가능하게 했지만, 유저 모델을 통합하고 recruiters로 분리한 후로부터 채용 공고는 해당 회사의 recruiters 권한 role을 받은 user만이 등록할 수 있도록 구현해야 할 것이다.
- 유저의 is_recruiter 값을 먼저 확인하고, recruiters 모델에 해당 유저가 등록되어 있는 유저라면 (동시에 company_id값도 확인) 회사에 대한 공고 등록이 가능하고, 공고 수정 및 삭제는 recruiter_id 값 확인을 통해 권한을 부여할 수 있을 것 같다.
- 채용 사이트를 분석하며 얻은 아이디어를 바탕으로 이력서 모델을 추가해보았다. 지원자(유저)는 여러 개의 이력서를 작성할 수 있으며, 채용 공고에 지원할 때 여러 이력서 중 한 가지를 첨부할 수 있다. 요구사항에서는 1인 1회 지원만 가능하기 때문에 resume를 모델로 빼지 않고, application의 칼럼으로 포함해도 되었지만 추후 확장 가능성을 고려하여 이력서를 모델로 따로 분리해 보았다.
- 지원자(유저)는 채용 공고에 지원을 할 수 있다. 이 때 이력서를 추가할 수 있으므로, fk값으로 resume id를 설정하였다. (추가 여부는 지원자의 몫이므로 null을 허용)