마침 2년 전 advent 달력에 이런 기사가 적혀 있었다.
나는 당시의 상황을 돌아보면서 현황을 정리하고 싶다

결혼식

관리에 의존하여 dep를 사용합니다.(dep가 나오기 전까지glide를 계속 사용합니다.)
2년 전과 비교하면 여러 가지 물건이 편리해져 보통으로 사용할 수 있게 되었다.
당시에는 고1에 불과했다.5시죠...

주로 사용되는 라이브러리

아무튼 이런 느낌입니다.

goa

gorm

상세한 상황은 여기에 있다
https://qiita.com/kyokomi/items/dcd8384a0a042d72d22d

포장은 무엇을 구성하는가

DDD책에 나오는 레이어드 빌딩을 워낙 의식하다 보니 어느새 바람양파 구조처럼 변했다.
지금 나는 이런 형식이 내 마음속에서 가장 좋다고 생각한다.

├── application
├── domain
│   ├── file
│   ├── friendship
│   └── user
├── infrastructure
│   ├── adapter
│   │   ├── auth
│   │   ├── aws
│   │   ├── cache
│   │   ├── firebase
│   │   └── rdbms
│   └── repository
└── presentation
      ├── controller
      ├── middleware
      └── view

패키지 이름
대응하는 양파 구조의 명칭
설명
presentation/controller
User Interface
gooa에서generate의 controller (http의Handler) 를 사용합니다.여기서 애플리케이션 서비스 호출
presentation/middleware
Request Header 같은 Middleware 확인
presentation/view
User Interface
gooa에서 정의한response에 마핑 및 쓰기
application
Application Service
domain/xxxx Repository 인터페이스를 통해 도메인 객체 가져오기 및 업데이트
domain
Domain Model
상업 논리.특정 infrastructure나view에 의존하지 않는 순수한 규범을 정의합니다
infrastructure/adapter
Infrastructure에서 나간 부분의 adapter입니다.
RDB, Redis 등 Cache, 외부 API 등과 교환
infrastructure/repository
Infrastructure
domain/xxxx의 Repository 인터페이스를 구현하는 struct

호출 프로세스

그림이 되면 이런 느낌의 호출 절차.(기분 좋으면 등사
친구 관련 기능을 예로 들 수 있습니다.(글씨가 더러워...)

※ 그림은 분위기 속에서 그린 그림이기 때문에 UML 같은 좋은 것은 아니다
화살표는 기본적으로 데이터 흐름이지만 인프라 시설인friendShip Repository가 지역 서비스인friendShip Repository 인터페이스를 가리키는 화살표만 계승한다

주안점

domain/xxx의 Repository를interface로 바꾸어 무의식적으로 내용의 실현(의존관계의 역전)

을 호출할 수 있다

RDB에는 두 개의 시계가 있기 때문에 두 개의 Object를 전달하는 것을 피하기 위해 Repository의 I/F 디자인이 중요하다

gooa에서generate의 Controller는 Application 서비스만 호출하고 결과를view에 전달하기 때문에 코드를 볼 필요가 없음

RDB의 디자인이나 과거 부채 등으로 이상한 데이터가 포함된 경우~이 경우 Repository의 인터페이스에 정의된 마퍼를 설치하여 흡수(부패층 방지)

맵퍼 정보

각 층의 데이터를 교환한 후 변환된 코드를 삐걱삐걱 쓰면 가독성이 떨어지기 때문에 마퍼를 적당히 쓴다
글로벌한 방법을 사용하면 사용 범위가 흐려지기 때문에 빈 struct를 만들어 방법의 생성과 정리를 해야 한다.(별도로 포장하지 않는 시스템)

type friendShipConvert struct {
}

var friendShipConverter = friendShipConvert{}

func (cnv friendShipConvert) toFollowTables(userID user.Identifier, followUsers friendship.Users) []*rdbms.UserFollowTable {
    result := make([]*rdbms.UserFollowTable, len(followUsers))
    for i := range followUsers {
        result[i] = &rdbms.UserFollowTable{
            UserID:       userID.String(),
            FollowUserID: followUsers[i].ID.String(),
        }
    }
    return result
}

func (cnv friendShipConvert) toBlockTables(userID user.Identifier, blockUsers friendship.Users) []*rdbms.UserBlockTable {
    result := make([]*rdbms.UserBlockTable, len(blockUsers))
    for i := range blockUsers {
        result[i] = &rdbms.UserBlockTable{
            UserID:      userID.String(),
            BlockUserID: blockUsers[i].ID.String(),
        }
    }
    return result
}

사내 공통 라이브러리

나는 보통 ClusterVR/go 이런 창고를 만들고 dep로vendoring을 한다.
신중을 기하기 위해rdbms/v1 이런 버전으로 바꿀 수 있는 디렉터리 파기 패키지명rdbms 같은 것들은 있지만 v2를 만드는 목표가 없기 때문에 지금 정말 필요한 것은 수수께끼

├── goa
│   └── middleware
│       └── v1
├── kvs
│   └── v1
├── mqtt
│   └── v1
├── rdbms
│   └── v1
└── sentry
    └── v1

굳이 불평을 한다면

각 층 간의 데이터의 마핑에서 매번 for문이나 근육으로 쓰기는 좀 번거롭다

덤

CI 정보

나는 CircleaCI->Wercker->CircleaCI 2.0의 역사를 찾고 있다.
워커는 가격이 비싸지만 멈추는 경우가 많아 부담이 컸지만, 써클씨아이 2.0 때는 도커 이미지를 활용할 수 있어 느낌이 좋아 옮겼다.
지금은 평화롭습니다

로컬 개발

docker-compose에 필요한 infrastructure와 마이크로 서비스화된 인터넷 알api 등을 모아 시작 확인 동작을 시작하는 느낌을 준다.
계속 작동하면 컴퓨터의 배터리가 급속히 줄어들어서 고민이에요...

감상

쓰고 싶었는데 안 쓰다가 2년 만에 이런 기분...
설치할 때domain/xxxx를 고려할 때 어떤 입도로 만들어야 합니까?등 주된 부분, 그 다음은 간단한 작업이기 때문에 설치가 바삭바삭하고 느낌이 좋습니다.
고민하지 않고 한꺼번에 만들어내고, 불협화음이 생기면 정리하고 팩스를 하는 절차가 좋다.
이상, 내년?어떻게 될지 기대가 되네요.