API 設計ガイド | Cloud API Design Guide | Google Cloud
フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR
CQRSとイベントソーシングの使用法、または「CRUDに何か問題でも？」 | POSTD
書き込みと読み込みのどちらに力を入れているかは、ストレージエンジンによって異なります。たとえば昔ながらのリレーショナルデータベースは、外部キーなどの制約を使ってデータの整合性をうまく制御できるようになっています。一方でNoSQLデータベースは、スループットとスケーラビリティを確保するために、そういった組み込みのガードレールをはずしてしまいました。データ層においても、どちらか一方に特化した最適化をすることがあります。たとえば、あらかじめ計算済みの値を保持しておけば、「一日あたりのサイト訪問者数」などの読み込み操作を効率よく行えるでしょう。ストレージソリューションのメーカーはどこも、「うちのプロダクトならあらゆるニーズを満たせます」などと自社製品の機能を自慢します。しかし実は、昔ながらのCRUDモデルに沿ってストレージエンジンを選んでデータ層を設計した時点で、さまざまな関心事の間で何らかの妥協
golang のレイヤ構造において、他のコードに影響なくインフラレイヤのデータソース実装を差し替えることは可能か? - pospomeのプログラミング日記
最近、golang のレイヤ構造において、他のコードに影響なくインフラレイヤのデータソース実装を差し替えることは可能か? という質問を受けた。 回答時間が限られている中で質問を受けたので、 「現実的には難しい」という雑な回答しかできなかった。 さすがに雑すぎるなと思ったので、 自分なりの回答をちゃんと残そうと思う。 影響を受ける対象となるコードは? MySQL -> PostgresSQL への差し替え MySQL -> WebAPI への差し替え インフラレイヤにDB依存のコードをまるっと実装してしまう DDDの場合 独自の接続オブジェクトを作る DDD本 & IDDD本のサンプルはどうなっているか? 差し替える必要はあるのか? まとめ 影響を受ける対象となるコードは?golang のレイヤ構造において、他のコードに影響なくインフラレイヤのデータソース実装を差し替えることは可能か? とい
モジュール結合度について - Qiita
はじめに 20日目は、（株）スマートテック・ベンチャーズの串田(@eKushida)が担当します。 プログラム設計の段階で、良い設計・悪い設計とはと議論になったときに、 チーム内で一つの統一された基準を持つのは大事ですね。 今回は、モジュール分割に着目して、お話したいと思います。 評価軸 説明 良い設計 悪い設計
DCIアーキテクチャについて語ってみるよ - uehaj's blog
Trygve Reenskaug氏とJames O. Coplien氏らが提唱する「DCIアーキテクチャ」について、id:digitalsoulさんが論文を翻訳してくださり、またその解説とサンプル実装(groovy, scala)を示してくださっており、読んでみたところ、大変興味深いので理解した限りを書いてみます。 おじさん登場 たとえば、あるおじさんがいたとします。 このおじさんは、白いスーツ、グラデーションの入ったサングラスと金ぴかのネックレスをつけて新宿歌舞伎町に出かけ「やくざ」として振るまいます。とおりかかったお兄さんがそのおじさんに出会い、目が合ってしまい、因縁を付けられ、お金を巻き上げられてしまいます。 さて、おじさんは家に帰ります。実は、このおじさんは家では良いお父さんとして振る舞います。赤ちゃんはこのおじさんの目を見て笑いかけます。おじさんは相好を崩し、オーよしよし。 さて
実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
ボトムアップドメイン駆動設計
はじめに この記事は前後編に分かれています。 順序だてた解説になっているので最後までお付き合いいただけると幸いです。 後編記事: https://nrslib.com/bottomup-ddd-2/ 順序立っての説明になっておりますので、前編からご覧になることを強くお勧めします。 セミナー情報 こちらの内容のセミナーを不定期で開催しています。 ◆セミナーページ 第一回: https://ddd-community-jp.connpass.com/event/103428/ 第二回: https://ddd-community-jp.connpass.com/event/107106/ 第三回: https://nrs-seminar.connpass.com/event/117283/ ◆あとがき 第一回ボトムアップドメイン駆動設計勉強会を開催しました セミナースライド まえがき この章は
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
レイヤー設計とか、オブジェクト指向とか、DDDとか、その辺 - まっつんの日記
自分の指向としては、技術の勉強というとDDDとかOODとか、そういう抽象的方面が好きなのだが、オブジェクト指向否定論もあることは承知している。 ---------------追記 2020/09/27 この記事は「ユーザーのメンタルモデルを反映させる」というMVCの本来の設計思想を捉えていません。ただ、巷に流布しているものを元に考えた記事としては資料的には無価値ではないと思いますので、ログとして残しときます。 MVCの本来の考えはOOUIの本や、コプリエンのLean Architecture本が良さそう ------------------------------- 過剰設計の落とし穴 実際、レイヤー構造や業務モデルを頑張って作っているが、実装時に足かせになったり、プログラマがよく規約や方針を理解できずに、ごちゃごちゃに作り、余計に複雑になってしまったりするのは、色々聞く。（自分はこれをや
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これから並ぶ方はま
今あえてDRY原則に向き合う
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
カーゴ・カルト・プログラミング - Wikipedia
カーゴ・カルト・プログラミング（英: Cargo cult programming）とは、コンピュータープログラミングにおいて、実際の目的には必要のないコードやプログラム構造が儀式的に含められているという状態で特徴づけられる悪習である。カーゴ・カルト・プログラミングは、プログラマが、自身が解決しようとしている課題やバグ、明らかな解決策を理解していないことを示す兆候である（ショットガン・デバッギング（英語版）やブードゥー・プログラミング（英語版）も参照）[1]。 カーゴ・カルト・プログラミングは、目の前の問題について経験の浅いプログラマが、他の場所にあるプログラムコードを、その仕組みや、それが本当に必要かどうかを理解することなしに、別の場所にコピーするときに生じうる。 また、他の場所で見つけてきた設計手法やコーディングスタイルを、それが生まれた背景理由などを理解しないまま盲目的に適用した結果
オープン・クローズドの原則（OCP） - Strategic Choice
オープン・クローズドの原則（OCP:the Open-Closed Principle）（開放−閉鎖原則） ソフトウェアの構成要素は、拡張に対して開いていて、修正に対して閉じていなければならない。どういうこと？オープン（開いている）とは？ モジュールの振る舞いを拡張できる。 クローズ（閉じている）とは？ モジュールの振る舞いを変更しても、そのソースやバイナリはまたく影響を受けない。 なんで？この原則はオブジェクト指向設計の核心。なぜなら、この原則に従えば、オブジェクト指向の最大のメリットを享受できる！ 柔軟性再利用性保守性たとえば？具体例として、よくある図形の例 。switch/caseで図形の種類ごとに処理を行う。 こうすると、図形の種類が追加になるたびにこの処理が変更になる。 ここで大事なのは、switch/caseがおそらく一箇所ではないところ。 至る所に図形の種類ごとの色々な処理が
リスコフの置換原則（LSP） - Strategic Choice
リスコフの置換原則（LSP:the Liskov Substitution Principle）派生型はその基本型と置換可能でなければならない。どういうこと？使う側から言うと、基本型を引数にとる関数に、どんな派生型のインスタンスをもらっても気にしないで使えないとダメ。実装側から言うと、派生クラスがその基本クラスで使われるところにおいても、正常に動作することを保証しなければならない。なんで？使う側に意識させるということは、OCPに違反することになるから。つまり、LSPに違反すると、必然的にOCPにも違反してしまう。たとえば？ではまず、簡単な例。Shapeクラス、そしてその派生クラスCircle/Squareがある。Shapeにabstract関数を使わない。Circle/Squareにそれぞれ独自のDraw関数がある。ここでShapeを受け取ってDrawする関数を作ろうとすると、、、、 v
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
SOLIDの原則ってどんなふうに使うの？