Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える20. レイヤ（ディレクトリ）構造 adapter handler presenter cmd presenter registry usecase input output domain model service repository infra dao mail adapter を置くこともあるが、 Webサーバ実装だと handler があれば事足りる事が多 いので、 最近は handler だけ置いて、 adapter 欲しくなったら adapter を置いている
golang のレイヤ構造において、他のコードに影響なくインフラレイヤのデータソース実装を差し替えることは可能か? - pospomeのプログラミング日記
最近、golang のレイヤ構造において、他のコードに影響なくインフラレイヤのデータソース実装を差し替えることは可能か? という質問を受けた。 回答時間が限られている中で質問を受けたので、 「現実的には難しい」という雑な回答しかできなかった。 さすがに雑すぎるなと思ったので、 自分なりの回答をちゃんと残そうと思う。 影響を受ける対象となるコードは? MySQL -> PostgresSQL への差し替え MySQL -> WebAPI への差し替え インフラレイヤにDB依存のコードをまるっと実装してしまう DDDの場合 独自の接続オブジェクトを作る DDD本 & IDDD本のサンプルはどうなっているか? 差し替える必要はあるのか? まとめ 影響を受ける対象となるコードは?golang のレイヤ構造において、他のコードに影響なくインフラレイヤのデータソース実装を差し替えることは可能か? とい
Go における FunctionalOptionPattern と MethodChaining について考える - pospomeのプログラミング日記
きっかけ FunctionalOptionPattern MethodChaining MethodChaining の問題点 Error フィールドによる解決方法 Error フィールドによる解決方法の問題 1. 各メソッドでエラーが発生しないような印象を受ける 2. エラーチェックを忘れそう その1 3. エラーチェックを忘れそう その2 FunctionalOptionPattern による解決方法 MethodChaining としての解決方法 Error フィールドの問題点は本当に問題なのか? どちらを使うべきなのか? まとめ きっかけこの記事を書くきっかけは以下のブログで、 MethodChaining の代わりに FunctionalOptionPattern を利用したという記事。 https://www.calhoun.io/using-functional-option
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える - pospomeのプログラミング日記
devfest 2017 tokyo の発表資料です。 Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える from pospome 当日は入室できない人もいたらしい & 機材トラブルで10minほど開始が遅れてしまった ということで申し訳なく思っています。 また、立ち見する価値がある内容を提供できたのだろうか? とも思っています。 スライドは単体でも発表内容が伝わるように文章を多めに載せているので、 是非確認してみてください。 100ページ越えていますが・・・。 #DevFest_room2 入れなかった。。— t.junichi (@tjun1) 2017年10月9日 ものすごい立ち見人数 #Devfest17 #DevFest_room2— バトルプログラマー柴田智也@少女終末旅行 (@tomoya_shibata) 2017年10月9日 ルーム2これから並ぶ方はま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
