과거 모놀리식 방식에서는 단일 어플리케이션 서버와 단일 db 구성으로 관리되어왔으며, 이때의 FK 는 거의 필수형태로 관리되어왔습니다. 하지만, 현대의 MSA 방식에서는 오히려 FK 가 강결합을 불러올 수 있고 db의 정합성 보장 메카니즘을 활용한 방식보다 어플리케이션 서버단에서 정합성을 맞추고 있는 상황으로, ORM 을 이용하여 DB 에 FK 를 세팅하진 않습니다. 또한 FK 를 추가함에 따라 발생되는 비용 중 일부가 insert, update 시간 지연, deadlock 이슈 등이 있는데, 이 비용에 비해 이점이 떨어진다는 시각이 많습니다. (물론 도메인 by 도메인, 회사 by 회사)
설계관점에서 바라보면, controller 단의 dto 와 service 단의 dto(domain) 을 공유자원으로 사용할 것인가? 분리해서 사용할 것인가를 고민해볼 수 있습니다. 어떤게 좋다? 라고 말하기에는 양측 전부 장단이 존재하여, 원하는 방식으로 사용하면 됩니다. 도메인 서비스 단에서 도메인 dto 로 return 만 시키고, controller layer 에서 static 을 이용하여 controller dto 로 변환하는 부분도 흔하게 사용되는 방식입니다. 이렇게 하게되면 비지니스 영역에서는 controller 의 dto 를 직접참조할 일이 없어지게 됩니다. (프로젝트 규모가 클 경우, 분리하는게 더 이익임)
특정 os 에 발생하는 현상으로 보이며, https://github.com/prisma/prisma/discussions/22519 링크 참조하여 generator client { provider = "prisma-client-js" } 내 binaryTargets = [ "native" , "linux-arm64-openssl-3.0.x" ] 추가 or prisma 경로를 변경해서 재시도를 권장드립니다.
"@prisma/client": "^6.2.1" 로 세팅되어 6.2.1보다 더 최신버전이 install 되었을것으로 추측됩니다. @prisma/client 버전을 6.2.1(4개월 전 LTS)로 고정해서 npm 을 재 설치해보시는 것을 추천드립니다. (6 점대 최신에서 계속 해서 여러 issue 발생 및 해결 중에 있음)
1번의 방식에서도 nest 가 알아서 싱글톤으로 관리를 해줍니다.(local module에만 국한), 타 모듈에서 불러와서 사용해야하는 전역 component 와 같은 영역 외 타 모듈을 import 로 불러오는 방식은 강결합 영역에서의 고민이 필요해 보입니다. 현재 강의영역의 범위 밖이긴 하지만, 타 모듈간의 자원에 대해서는 직접적인 DI를 모두 제거하는 것이 좋습니다. (모듈끼리의 결합도를 없애고, 모듈 내 응집도를 높이는 방식)
AI 인턴이 답변을 잘 달아놓았는데 좀더 추가설명을 드리면, global service 를 고려할 때 자동생성 DB 시간을 local 시간으로 둘 경우 일관성유지가 어렵고 국내에는 해당되지 않지만, 써머타임이 존재하는 국가도 있기때문에 관리포인트가 늘어나게 됩니다. 따라서 @db.date 과 같이 UTC 기반으로 사용 후 application layer 에서 시간변환하여 사용하고 있습니다.
아키텍처에 대한 설명 추가 및 default 로 생성되는 코드를 제거하자!라는 의미였는데(nest 명령어로 자동생성되는 코드들), 설명이 다소 부족한 거 같아 해당부분에 대한 보완강의를 제작 중에 있습니다. 빠른시일이내 업로드가 될 예정이오니 업로드 되면 추가 댓글 남기도록 하겠습니다.