Golang 으로 REST API 서비스를 만들 때 package 로 왜 묶지?

http 일반적으로 api 를 만들때

왜 패키지를 묶지? 찾기쉽게 구분하기쉽게

청킹

chunk

번들링 ?묶는다

chunk.js 덩이짓기 의미있는덩어리

파라미터 4개 이상이면 struct 로 덩이짓는다 마법의 숫자 사람의인지 범위에서 벗어나는 순간 파악하기 어려워서 패키징 한다

파일을 패키징하면 구분하기 쉽게 하기 위해서

질소가많이들어갔다

미리하지마라 you aren't goonna need it

엔지니어링 이건 왜하지 패키지은 왜하고있지 클린코드

동작하면서 품질이 높은 코드 2000년간 공학적 설계지식으로 정해진

비오면무너지니까

=>

error type converting

errors is 로 판단해서 record 가 없으면 컨드롤러에서 특정 코드를 보내는 것은 컨드롤러에서

gorm 이나 xorm 에서 온 error 객체를 가 바뀌면

의존성이 전파되서 타이틀리 커플드 수정하기 좋다

안티패턴중 하나는 web framework echo ,진 등 과의 접접은 컨트롤러인데 서비스에서 쿠키를 사용하면 안티패턴..

db 의존성이 repositoy 에만 있디 모르면 모를수록 의존을 안한다

entity 로직에는 비즈니스 로직을 조정할 뿐이지 func 에서

서비스에 비즈니스 로직을 넣는 방식을 트랜잭션 스크립트 패턴

마틴파울러

=>마이크로서비스 만든 사람

패턴오브엔터프라이즈아키탣처

규모가 큰 어플리케이션의 패턴이 있더라 문제에는 특정의 형태를 띄더라

대규모 시스템에는 아키택처가 패턴이 있더라

서비스에 비즈니스로직이 듷ㄹ어가는 트랜잭션 스크립트 패턴 장점:간단한 시스템에는 좋다 => 직관적이고 간단한 프로그램들 ]프로그래밍 성숙도가 낮은 사람들한테 좋다

단점은 서비스에 로직이 많아지는 경우가 있다

1000줄넘어서 인지의 범위가 넘어간다면 fuction 으로 남겨도 많아지면 인지의 범위가 늘어단다

야 그렇게하니까 유지보수가 안되는거야 간단하고

최대한 인지하는 것을 줄여야한다

OOP 를 하는거야

서비스는 entity에 위임해 델리게이션

니가무슨짓읗 하던 상관없고 그냥

의존성 의 타이플리 vs 루즐리 커플드

인터페이스를 통해서 메세지를 보내면 끝

의존성은

에그리디패턴

entity 가 => 묶음단위

gorm

에그리게잇

entity 에 root entitty 를 기준으로