합격

개괄해 보면...

대오 중 속도가 가장 빠른 상태에서 고응집의 희소한 결합이라면
읽는 쪽이 부담스럽지 않나 해서요.

전제 조건

사업이라면 예산과 수익이 필요하다
예산과 품질의 절충이 있다
설계와 실제 조립 기간의 균형이 붕괴되다
기본 품질 수준의 담보.
마음대로 할 수 있다면 할 수 있을 것 같아요.

DDD랑 Clean Archeitecture가 이해가 안 가요.
자기가 반대로 알려주고 싶은 수준이야.

구조를 재고하는 계기

혼자 한번 구성을 고민하고 팀 내에서 댓글을 달았지만.
제작해서 발매하는 건 좋은데 이 구성이 정말 맞는 건가요?
누가 보면 이해하기 힘들겠죠?
이런 의문이 생겼기 때문이다.

구조가 전파될 때까지

참고 기사를 많이 보니 각 회사의 대층 구분이 일치하지 않는 것 같다.
응, 결국 팀 내에서 공감대가 형성되었어.이런 인상이 중요한데.
하지만 이런 일에 관심이 없다면 기능을 발휘할 수 있었으면 좋겠다는 의견도 있다
그 입장이 있는 사람이라면 문서를 만드는 비용이 높아질 것이다.
몇 년 후, 처음 구조를 고려해도
이직이나 전근으로 제작자가 없어져 구조가 붕괴되다
어느 정도의 속박이 있어야 한다고 생각해요.
나는 난이도가 높은 구조는 채택하기 매우 어렵다고 생각한다.
(여기서부터는 개인의 주관성)
그리고 업데이트의 유지와 확장성을 고려하여
DDD 레이크 형태로 가벼운 형태의 포장 구성이라면
독자와 작가의 부담감에는 문제가 없겠죠?내 생각엔

어디로 분할해야 합니까?

평소에 고 언어와 php를 사용하기 때문에 편파적인 의견이 생길 수 있다

구조, 인터페이스 부분에서 읽은 사람

도메인 이름으로 묶어서 읽는 사람
두 가지로 나눌 수 있지 않을까 해서요.

나는 도메인 이름에서 본 것처럼 대충 이해했을 뿐이다.
나는 어느 것이 정답이라고 말하는 것이 아니라고 생각한다...
다만, 쌍방이 모두 받아들일 수 있다면 좋겠다고 생각합니다.
나는 응집도의 정의는 사람에 따라 다르다고 생각한다.
읽는 쪽과 쓰는 쪽의 부담이 높지 않다
어떻게 써야 습관이 됩니까?그래서
예: 디렉토리 구조(참조)

├── application
│   ├── usecase
│   │   └── A_usecase.go
├── domain
│   ├── model
│   │   └── A_model.go
│   └── repository
│       └── A_repository.go
├── infrastructure
│   └── A_repository.go
├── interfaces
│   └── api
│       └── server
│             └── server.go
│       └── handler
│             └── A_handler.go
│	└── router
│	      └── route.go

총결산

수다 떠는 것 같아.
어떻게 구성해야 좋을까요?계속 고민하고 있어요.
정답은 안 보이지만.
나는 지나치게 구속되어 전진할 수 없는 것을 피하고 싶다
여러분의 의견을 듣고 싶습니다.
만약 현장에서 구조를 바꾸는 것이 있다면 반드시 저에게 알려주세요.