技術系の境界線 | La Verda Luno
これは 設計ナイト2020 の感想記事です。 CQRS と GraphQL の話が主な話題でしたが、ディスカッションなどで示唆に富む話を聞けたので、（レポートというよりも）考えたことを書き残しておきます。 発表内容についてはあまり書きませんが、すでに 設計ナイト2020感想 - Qiita と 設計ナイト2020に参加してきました。 | achanBlog という記事があります。 Q&A やディスカッションについても #sekkeinight 付きのツイートを見ると、何が交わされたか把握できると思います。 コンテキスト DDD・CQRS・GraphQL・アーキテクチャの進化戦略などについて深い話（触ってみたレベルでなく実運用等を経たもの）についても興味深かったのですが、サーバー再度にとっての理想的なモデルとフロントエンドの要求が衝突する境界線について考えるきっかけになりました。もしかしてサ
チームのWeb API開発を最適化するSchema Driven Developmentの解説＆実装例 - Qiita
チームでのWeb API開発において、進行を妨げる要因は様々な形で噴出します。 「フロントはバックエンドのAPI実装待ちなので動けません...」「ドキュメンテーションのコストが重い...」「ドキュメントと実装が全然違うので参考にならない...」 また、APIスキーマ設定が不十分だと、ビジネスドメインの最低原則やクライアント側のニーズを理解せずに、バックエンド都合のAPIがそのまま実装される危険性もあります。 そうした問題を解決すべくSchema Driven Developmentと呼ばれる開発手法が生まれました。 Schema Driven Developmentとは？ Schema Driven Development(以下SDD)とはチームにおけるWeb API開発フローを改善する開発手法の一つです。スキーマ駆動開発やSchema First Developmentとも呼ばれています
Modular Monolith(モジュラーモノリス)の記事とか色々読んでみた
最近Modular Monolith(モジュラーモノリス)というアーキテクチャについての記事を色々と読んでいます。 個人的に面白いアーキテクチャかなと思っているのでメモがてらまとめてみたいと思います。 目次 Modular Monolithとは 記事 Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity The Modular Monolith: Rails Architecture Shopifyはいかにしてモジュラモノリスへ移行したか Modular Monoliths — A Gateway to Microservices モジュラモノリスで表現する複雑なドメイン領域と境界 【2020/10/25追記】 終わりに Modular Monolithとは そもそもMod
認証と認可と課金とコアドメインを分離したシステムは勝てるという話 - まっちゅーのチラ裏
自分が複数のシステムの開発を経験して得た確信として、「認証と認可と課金とコアドメインの分離がめちゃくちゃ重要である」というものがあるので、コレを整理してアウトプットしていく 分離するモチベーションとは Microservice文脈でいうと、デプロイ独立性だったり、リソースの最適配分だったり、障害の局所化だったり、開発組織とのマッピングだったりがメリットとして語られることが多い。 だが、ここで取り上げたいのは戦術的DDD的観点でのコンテキスト分離の有用性である。 ※ちなみにコンテキスト分離のみであればモジュラモノリスだけで実現可能。 戦術的DDD的観点での関心事の分離によるメリットとは コンテキストが分離されていることによって、境界をまたぐ際に「このI/Fは正しいのか？」を都度考えることを強制することができる。 境界がなければ意図しない密結合を生みやすくなってしまう。 もちろん、境界を超える
マイクロサービス設計原則: SOLIDではなくIDEALS
キーポイント For object-oriented design we follow the SOLID principles. For microservice design we propose developers follow the “IDEALS”: interface segregation, deployability (is on you), event-driven, availability over consistency, loose-coupling, and single responsibility. Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to inte
CQRSはなぜEvent Sourcingになってしまうのか - かとじゅんの技術日誌
CQRSはなぜEvent Sourcingになってしまうのか、まとめてみたいと思います。 なぜまとめるか、それはCQRSにとってEvent Sourcingはオプションだと誤解されている方が多いからです。この記事を書いてる本人も最初はそう思っていましたが、実際に開発・運用を経験してみるとCQRSにとってEvent Sourcingはほぼ必須で、認識を改めるべきだと気づきました。なので、原義に基づいたうえで、Event SourcingではないCQRSがなぜよくない設計になるのか解説します。 その前に松岡さんの記事について。 CQRSの領域ではモデルを完全に分ける 松岡さんの記事には”CQRSはモデルを完全に分ける必要はない”と書かれていますが、知識がないと誤解しがちですが文字のまま意味を取るといけません。こちらの言及は、システムのうち、モデルをC/Qに分割するCQRS領域とモデルを分割しな
秒間3万リクエストをkubernetesでさばく - Gunosy Tech Blog
こんにちは！スタンディングデスクを導入して快適な開発環境と運動不足の両方を解消できるようになったのではと感じている、広告技術部のUT@mocyutoです。 今回は半年ほどEKSを運用して秒間3万リクエストのトラフィックをさばくほどになりました。 秒間3万は広告システムだと割とあるとは思いますが、kubernetesでも運用できているので紹介しようと思います。 対象のEKSで構築したサービスは広告の配信サーバです。 広告配信サーバの要件として、まず50ms以内にレスポンスを返さなければいけません。 構築したk8sのレスポンスタイムの99パーセンタイルは10msほどで返せています。 以下は必要最小限のクラスタの構成図です。 全体像 API 弊社のサーバサイドはほぼGoで作られているので、例に漏れずGoで作られています。 pod構成はAPI、fluentd、envoyの サイドカーパターン です
マルチランタイム・マイクロサービスアーキテクチャ
状態(state)を話題にする場合、その多くはサービスの状態や、ステートレスが望ましい理由といったことが多いのですが、サービスを管理するプラットフォーム自体にも状態は必要です。信頼性の高いサービスオーケストレーションの実行、分散型のシングルトン、時間的スケジューリング(cronジョブ)、冪等性、ステートフルなエラーリカバリ、キャッシュなどを行なうには、状態が必要になります。ここで挙げたすべての機能が、内部的に状態を持つことに依存しているのです。状態管理の実際はこの記事の範囲ではありませんが、状態に依存する分散プリミティブやその抽象化は関心の範囲内にあります。 バインディング 分散システムのコンポーネントは相互の通信が必要なだけではなく、最新の外部システム、あるいはレガシな外部システムとのインテグレーションも必要です。そのためには、さまざまなプロトコルを変換し、ポーリングやイベント駆動、リク
11種類のオペレーティング・システムについてまとめてみた - Qiita
TL;DR 「オペレーティングシステム？知ってるよ。WindowsとかMacのことだよね」というぐらいの知識だった私が、二週間ほどひたすらWikipediaでインプットしまくったクソ浅い情報を共有します。 最初の動機 「Go言語が対応しているアーキテクチャってなんだろ？」 Go言語には環境変数をコンパイラに渡すことで、出力されるバイナリの対応するOSとアーキテクチャを変えることができます。 GOOS がオペレーティングシステム(OS)、 GOARCH がアーキテクチャです。 こんな感じにビルドすると、 linux というオペレーティングシステムで、 ppc64 というアーキテクチャに対応したバイナリが出力されます。 なるほど。 じゃあ、 Go言語が対応しているOSとアーキテクチャって何があるの？ と疑問が湧いてきますね。 その疑問に応えるコマンドが go tool dist list です
実践クリーンアーキテクチャ【プログラミング】
音ズレ修正 Ver. → https://www.youtube.com/watch?v=BvzjpAe3d4g 本編 → 7:08 ～ JJUC CCC 2019 Spring の講演「「先行開発！クリーンアーキテクチャ -- ゼロから始める新規開発」の再演です。 講演の概要は下記URLのイベントページをご覧ください。 # URL イベントページ: https://nrs-seminar.connpass.com/event/174000/ Togetter: https://togetter.com/li/1502339 文字起こし（ログミーTechさま）: https://logmi.jp/tech/articles/323233 スライド: https://speakerdeck.com/nrslib/clean-architecture-with-java github: h
Clean Architecture の勘所は『鎖国』だ。 - Qiita
■ クリーンアーキテクチャって難しい。 クリーンアーキテクチャって難しいですよね。 この有名な同心円状の図、何度見てもよくわかりません。右下にある矢印もよくわかりません。 様々な記事を見ても、やっぱり分かるような分からないような... プロダクトに COM 通信が必要になったので勇んでクリーンアーキテクチャを採用したはいいものの、 どうにも理解しきれず泣きながら必死に試行錯誤をしていたところ、 ふと クリーンアーキテクチャは『鎖国』に例えると分かりやすい という事に気が付きました。 本記事では初心者なりにその言語化にチャレンジしてみたいと思います。 ※ なお考え方そのものに着目するため、コードは全く取り扱いません。その点ご了承ください。 またクリーンアーキテクチャは、表面的なメリット(ユニットテストしやすい等) だけを見て批判されてしまうことも有るようです。 その辺りについても少し触れてみ
電子情報学特論：Chromiumのアーキテクチャを解き明かす
電子情報学特論： Chromium のアーキテクチャを解き明かす 〜 EEIC の授業が生きるプロダクトの世界〜 Kentaro Hara 2020 April (๑>ᴗ<๑) * * * *
マイクロサービスのための分散データ 〜 イベントソーシング vs チェンジデータキャプチャ - 赤帽エンジニアブログ
インテグレーションのためのミドルウェア製品のテクニカルサポートを担当している山下です。 今回は レッドハットのシニアアーキテクトである Eric Murphy さんによる「マイクロサービスのための分散データ 〜 イベントソーシング vs チェンジデータキャプチャ(CDC)」の翻訳記事です。この記事では、イベントソーシング、CDC、CDC + Outboxパターン、CQRSをそれぞれ簡単に説明しながら、それらの特性の違いを比較します。また、イベントソーシングとCQRSの簡易な説明がなされている他、あまり明確に語られることが少ないもののソフトウェアの設計に大きな影響をおよぼすドメインイベントとチェンジイベントの違いにも触れられています。 [原文] Distributed Data for Microservices — Event Sourcing vs. Change Data Captur
ソフトウェアアーキテクチャを学ぶために - kawasima
いわゆるGoFの23個のデザインパターン。知っておくに越したことはないが、フレームワーク・ライブラリに溶け込みすぎていて、現代では知らないうちに使ってることになるので、余裕があれば。
マイクロサービスを形式的に見てみる - Juju-62q's blog
マイクロサービスについて考えていたら疲弊したので、少し技術者らしく形式的に見てダメのものを思考から削ぎ落としたいと思った。 グラフ理論などコンピュータサイエンスの基礎を交えて話をするが、基本的には当たり前のことしか言わないと思うのでここに書くことを意識せずとも暗黙的に実践している人も多いだろう。 なお、個人の意見でしかないのであっているか間違っているかはわからないし、筆者にこの記述に反した実装を否定する意図はない。 今回は適当に書き散らかすのでかなりテイストが違うが他のブログと同一人物が書いている。乗っ取り等ではないです。 TL;DR マイクロサービスはDAGとすると考えやすいしデプロイしやすい 閉路があるなら設計を見直した方がいい DAGかどうかはサブシステムレベルでそれぞれ考えると簡単 デプロイに関係するリポジトリでは閉路がないことを意識させる設計にするといい マイクロサービスと疲弊
GoF デザインパターン チートシート - Qiita
ここまで読んでくださった皆さんに、ちょっとしたクリスマスプレゼント。マンガでわかる GoF デザインパターン 23 種チートシートです。これでもうデザインパターンは完全にマスターしましたよ。やったね! (注: ここからはあとがきポエムです) ところでみなさん、せっかくデザインパターンを学んだので、これを使ってプログラムを書こう、チートシートがあるからなんでも書けそうだぞ、なんて思っていませんか。ダメですよ。そんなことしたら 2000 年前後に起きた失敗を繰り返してしまいます。 実は GoF のデザインパターンは、ビジネス的には成功したけど、教育には失敗しました。最初に出版された本に「オブジェクト指向における再利用のための」という肩書が付いていましたが、これが本当に良くなかった。 あの頃 (ポール・グレアムが LISP と Ruby を褒めるまで) は、「オブジェクト指向様こそが良い設計のす
マイクロサービスにクリーンアーキテクチャを採用する上で考えたこと | メルカリエンジニアリング
Merpay Advent Calendar 2019 の19日目は、Backendエンジニアチームの @toshinao がお送りします。 新しくマイクロサービスを立ち上げる機会があり、クリーンアーキテクチャをベースにしました。クリーンアーキテクチャはバックエンド・フロントエンド・アプリなど様々な場所で採用されています。ただ、確固たる方法というのは無く、みな試行錯誤しているのでは無いでしょうか。この記事では、クリーンアーキテクチャを取り入れる上で考えたことを紹介したいと思います。 マイクロサービスを作ったことがない人や、今までいくつか作ってきたけどより良い設計について考えている人の助けになれば幸いです。 はじめに メルペイのバックエンドは主にGoとGoogle Cloud Platform（GCP）で開発を行っていますが、各マイクロサービスをどう実装していくかは概ね各チームに委ねられてい
Lambdaの内部アーキテクチャ教えます！A serverless journey: AWS Lambda under the hood #SVS405 #reinvent | DevelopersIO
CX事業本部の岩田です。 昨年re:inventから帰国後にyoutubeで見つけたセッション「A Serverless Journey: AWS Lambda Under the Hood」が非常に興味深い内容でした。今年も同様のセッションが無いかre:inventのセッション予約開始前からチェックしていたところ、なんと今年も同じタイトルのセッションがありました。これは現地で聞くしかない！ということで聞いてきましたので、改めてセッション内容をまとめてレポートします。 資料 セッション動画 スライド A Serverless Journey: Under the Hood of AWS Lambda 例年ならSlide Shareで公開されるのですが、今年に関しては今のところSlide Shareには上がっていないようです。なお以後登場する画像のほとんどはこちらのスライドからの引用となりま
CSS Architecture on Vue.js
Open standards for building event-driven applications in the cloud
『Design It! ― プログラマーのためのアーキテクティング入門』 - snoozer05's blog
翻訳を担当した書籍『Design It! ― プログラマーのためのアーキテクティング入門』（オライリー・ジャパン）が11月25日に発売になります。本書は2017年にPragmatic Bookshelfより出版されたMichael Keeling著『Design It!: From Programmer to Software Architect』の全訳です。Pragmatic Bookshelfファンにはおなじみの「... It!」シリーズの一冊で、日本語で読める「... It!」シリーズとしては4冊目の書籍となります。 O'Reilly Japan - Design It! 本書は、設計スキルを成長させたいプログラマーに向けたアーキテクティングの入門書です。ソフトウェアアーキテクチャの基礎とデザイン思考の考え方から始まり、ソフトウェアアーキテクトとして、チームと共に優れたソフトウェアを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
