-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Api stablizing #6
Conversation
@@ -30,6 +32,42 @@ type UserUsecase struct { | |||
kc keycloak.IKeycloak | |||
} | |||
|
|||
func (u *UserUsecase) DeleteAll(ctx context.Context, organizationId string) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DeleteAll 이 꼭 필요한가요?
이런 list 형식의 데이터 변경 API 는 아래가 고려되어야 합니다.
- 반복문 중간에 error 가 발생했을 경우, 어떻게 처리할 건지.
- 중간에 지금처럼 스톱인지
- 스톱이라면 partial success 처리할 것인지, 전체 rollback 할건지.
- skip 인지
- skip 이라면 partial success 처리에 대한 response 를 정의해서 성공한 내역을 return 해주야 하겠습니다.
- 중간에 지금처럼 스톱인지
@@ -57,7 +57,35 @@ type CreateOrganizationRequest struct { | |||
Phone string `json:"phone"` | |||
} | |||
|
|||
func (r *CreateOrganizationRequest) ToOrganization() *Organization { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
input 을 Organization 객체로 변경하는 의도가 있는지요.
불완전한 객체를 전달하는것보다 직접 request 객체를 usecase 로 전달하는게 어떨까요?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
transport layer - usecase layer - repository layer 간의 DO가 Domain으로 생각하여 transport에서 불완전하지만 객체를 만들도록 하였습니다.
논의 결과(/w @ktkfree 님) :
3가지 종류의 DO 정의
- Client <-> API server 간의 Request Response에 대한 구조체.
- transport <-> usecase <-> repository 레이어 간의 DO에 대한 구조체(domain)
- repoistory <-> DB 간의 DO(DB schema)
해당 작업은 따로 날을 잡아 진행하는게 좋아보입니다
No description provided.