Goのパッケージ構成の失敗遍歴と現状確認

この記事は Gunosy Advent Calendar 2017の5日目の記事です。前回の記事はGunosyのパーソナライズを支える技術 -ワークフロー編-でした。 GoでAPIを書くときの問題僕の在籍するGunosyはGoを昔（？）から本番採用しておりまして、ノウハウも潤沢に溜まっている企業だと言えます。 しかし、contextの扱いやベストなパッケージ構成、テスト、net/httpでAPIを書くノウハウなどなど、迷うことは多々あります。 これは弊社特有の事情ではなく、Goのサーバーサイドエンジニア全員にとっての問題です。中でも、パッケージ構成をどうすればいいのか（相互参照せずに快適に開発を進められるパッケージ構成とは）を見つけるのは結構難しく、各々のチームにお任せ、という状況です。 今回は上記の問題のうち、パッケージ構成に踏みこんで見たいとおもいます。会社でもよくパッケージ構成をどう

[j5ik2o]

タイトルのそれというよりDDDやろうとした苦労話かな。お疲れ様です！

[syou6162]

これは知見の塊では...

[Songmu]

めっちゃ良い

[nkkkun]

Go API構成について

[ikaro1192]

失敗はなかなか共有されないだけによい記事

[zoe302]

すごい、よくわかる記事。goに限らずアプリケーションのレイヤ分けに迷ったら読むといい。

[akatakun]

CLIツールや小さめのサーバー、あるいは小さめのパッケージなどはmainにまとめる，MCVは相互参照で辛い，libraryはutilsほど細かくなく、切り出してもいいレベルのもの

[t-akihito]

golang

[masudaK]

悩んだところとかも書かれててすごく参考になるけど、結局何が最強かは分からない

[mather314]

失敗事例を示していただけてありがたい

[kenichi_odo]

APIベースで実装してるからパスごとにフォルダ作ってる

[zetta1985]

パッケージ構成整えたからといって、DDDできているとは限らないのでは

[restartr]

bounded contextは1つだけなのだろうか？

[taguch1]

現状似たような構成になってるっぽい。

[ono_matope]

パッケージ構成めっちゃ悩む。

[honeningen]

Goあんま関係ない

[digo]

特に、デカい業務アプリ作るときのノウハウが見つからず辛い。。コマンドとかミドルウェアとかの知見は散見するけども。。 “Goはまだまだ現場ノウハウと言えるものが、表に十分出てきているとは言えません”

[ktakeda47]

（言語はあまり関係なさげ？）

[cocoasynn]

なるほどー

[keepkeptkept]

めっちゃ参考になった

[razokulover]

参考になりすぎる

[Konboi]

めちゃわかりみ / 参考にさせていただきます🙏

[massa142]

パッケージ構成で悩むのわかる。個人的にはプロジェクトルートに展開していくのがGoらしくてやりやすい

[Tomato-360]

まだこに行き着くまで苦しんだことないけど参考になる

[utahta]

めっちゃわかる

[h3poteto]

すごくよくわかる．いつもその時々で一番いいとおもうレイヤー構造作るけど，だいたい依存がきつくなっていく

[golden_eggg]

第2ケース以降の迷子経験的に、超ありがたいまとめだ

[peketamin]

“僕なりに試行錯誤したGoのAPIの失敗遍歴と、現状のパッケージ構成の確認” ありがたいです…mm

[honeybe]

「20個とかファイルが乱立していると結構ウッときます」「闇を抱えがちなServiceレイヤー」

[daichirata]

分かる。自分も設計のためのレイヤ分けはかなり色々考えたけど、Goではパッケージとして独立出来るかくらいで後はフラットに置くのが結局やり易いかなという結論に落ち着いてる