서비스 계층 및 저장소의 책임

Question

내 서비스 및 저장소와 함께 줄을 그릴 위치에 대한 조언이 필요합니다.

아바타 모델은 컨택 모델에서만 사용되며 컨택의 선택적 속성이라고 가정 해 보겠습니다. 내 저장소가 연락처에 아바타를 추가해야합니까? 아니면 비즈니스/서비스 계층이 해당 기능을 확장해야합니까? 아바타를 소유하는 것이 비즈니스 요구 사항이라고 주장 할 수 있지만 모델의 일부이므로 데이터 계층에서는이를 처리하는 방법을 알아야합니다.

우리는 저장소를 통해 아바타 추가/업데이트 및 제거 기능을 추가 할 수 있다고 제안했습니다. 비즈니스/서비스 계층은 실제 파일 저장, 유효성 검증 및 저장소에서 적절한 메소드 호출을 담당합니다. 저장소에 대한 모든 관심은 적절한 연락처를 첨부하고 아바타를 추가하는 것입니다.

아바타가 연락처에서만 사용 중이므로 현재는 저장소를 확장하여 DAL에 기능을 추가 할 것이라고 생각했습니다. 이것은 별도의 API에 유용 할 수 있습니다.

Answer 1

제 의견으로는이 정보를 리포지토리에 추가하는 것이 아니라 비즈니스 계층에 정의하는 것입니다.

도메인 기반 디자인을 따르는 경우 Contact은 Avatar을 만들고 올바른 속성을 설정하는 데 도움이되는 AddAvatar 메서드가됩니다.

리포지토리는 집계 루트에 대해서만 만들어집니다. Avatar은 Contact에만 액세스 할 수 있으며, 데이터 레이어에는 AvatarRepository이 포함되어서는 안됩니다. 해당 연락처를 통해 Avatar로드 할 수 있습니다.

또한 실제 파일 저장에 BLL이 책임이 있다고 명시합니다. 나는이 물마루가 잠시 동안 생각할 것입니다. 귀하의 BLL에있는 실제 파일을 다루는 코드를 정말로 원하십니까?

스케일링 및 백업을 위해 아바타 파일을 데이터베이스로 옮기면 갑자기 해당 코드가 저장소로 이동하게됩니다. 리포지토리는 생각 프로세스에서 데이터베이스에 즉시 매핑하지만 데이터 저장소의 일반적인 용어이며 물리적 파일도 저장할 수 있습니다. 우리는 저장소가이를 어떻게 구현하는지는 신경 쓰지 않습니다. 우리가 신경 쓰는 부분은 비즈니스 문제가있는 비즈니스 로직을 작성하고 인프라 문제에 대해 걱정하지 않는 것입니다.

그래서 Avatar을 BLL로 수정하고 실제 파일을 다루는 코드를 Repository으로 변경하는 코드를 옮길 것입니다.