パッケージ構成っていつでも悩ましいGo Conference 2017 Autumn

2017/11/5

Future Architect Inc,Keigo Suda(@keigodasu)

＊ エンジニア@FutureArchitect.Inc＊ ⽇頃はKafka、Sparkとか⼤きなデータを扱うミドルウェアが専⾨＊ 「君のJava僕のJava」に疲れてGoを導⼊し始めた

須⽥桂伍 (すだ けいご)

@keigodasu

※のちほど英訳版もアップしますm(_ _)m

最初に結論l パッケージ構成の⼤切なことはここに書いてある（まずはこれを読め）l そして話すことがなくなった。。。😇

ü パッケージ構成のパターンü DDDライクなパッケージ構成実例ü インタフェースによる実装ü and more ...

パッケージを決めるための考慮ポイントl ⾒通しの良さ

l 機能配置の視認性(どこに何があるか分かる,サイクルインポートさせない作り, ・・・)l テストのやりやすさ(テスト実⾏の単位, ・・・)

l 再利⽤のしやすさl 独⽴して利⽤できる機能l internalパッケージの利⽤

l 詳細の隠蔽l パッケージ間の連携はインタフェースで

l あげればきりがない・・・

規模の⼤きなシステムを作る時の選択肢は？🤔l ライブラリ系/ミドルウェアはOSSを漁ればお⼿本はたくさんある

l こんな感じで作ればいいなっていう勘所は⼗分つかめる

l 規模の⼤きいシステムをGo未経験者も含むようなチーム(10⼈~)で作る際のお⼿本はあまりみかけないl GopherCon等含め意外とパッケージ構成のパターンに⾔及してるものは少ない

l 本LTでは特にここについてどう考えるようにしているかお話しますl インタフェース設計の話などテクニック的な話はないです🙇

ちまたの流儀？l Golang Package Composition for Web Application: The Case of

Mercari Kaurul https://speakerdeck.com/mercari/ja-golang-package-composition-for-web-

application-the-case-of-mercari-kauru

l Standard Package Layoutl https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1

l Go and a Package Focused Designl https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1

でも現実は。。。😎l DDDを意識としたパターンが多い気がする

l Goとはいえオブジェクト指向的な考えも必要で、メンバ構成次第では機能配置等で維持メンテ、レビュー⾟い時もある。

l そこそこ⼤きなシステムを経験者/未経験者混合チームで作る時はトランザクションスクリプトの余地も残しておく必要あってまた悩ましい

どのように判断しているか(Goに限らず)l ⽐較的シンプル/未経験者も多い時はRailsライク(model/controller)

l Pros) ちまたのノウハウを取り⼊れやすい/ある程度の同品質を保ちやすい(新規参画者が馴染みやすい)

l Cons) prosの裏返し。⼤きくなるにつれどんどんGoっぽさがなくなってくる感じがする

l 経験者が多い時はDDDライク(厳密なDDDではなく・・・)に近づけてくl Pros) Goではみかける事が多く、その点では参考情報も得やすいl Cons) オブジェクト指向的な考え経験がないと維持つらい

例）センサデータ受け付けるAPIサーバl ~5⼈(Go経験1⼈/Java経験4⼈)ほどで開発した際のパッケージ構成l Javaユーザへの導⼊としては意外とはまる（Goらしいかというと、、、）

・┗━━ data-uploader

┣━━ main.go┣━━ api┃ ┣━━handler.go┃ ┗━━route.go┣━━ controller┃ ┣━━event.go┃ ┗━━sensor.go┣━━ service ←作らない時もある┃ ┣━━ topic_routing.go┃ ┗━━ ・・・┣━━ model┃ ┣━━event.go┃ ┗━━sensor.go┗━━ util

┣━━ xxxutil┃ ┗━━ ・・・┗━━ ・・・

https://www.slideshare.net/keigosuda/iot-72733494

ココのところ

ちなみにパッケージ名どう考える？🤔

GoPhoerCon 2017 - Go Anti-Patterns

ちなみにパッケージ名どう考える？🤔l encodingパッケージなども例としてわかりやすい

ほんとすいません🙇🙇🙇🙇🙇🙇🙇🙇🙇

Golang UK Conference 2016 - Building an enterprise service in Go GoPhoerCon 2017 - Go Anti-Patterns

l よく使われているのには理由がある？l これぐらいのよくあるネーミングの⽅が未経験ユーザへの導⼊はしやすい？

まとめl 新規導⼊時など、ときにはGoに⼊ればGoに従わない勇気も必要なシーンも

多々あったl もっとパッケージ構成の⽣々しいノウハウやパターンが発信されるといいのかも

Golang UK2016keynoteDaveCheney

ありがとうございました!!