世界最強のソフトウェアアーキテクト
2021年9月18日に開催されたXP祭り2021での講演「マイクロサービスに至る歴史とこれから」の講演資料です。 https://xpjug.connpass.com/event/218516/ This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like K
DDDで設計するならCQRSの利用を検討すべき - Qiita
タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日本語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」（副作用あり）と「クエリ」（副作用なし）で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。 一貫性： 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし ストレージ： 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的 スケーラビリティ： 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい なので分けちゃうわけですが、 コマンド側 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍 クエリ側 複雑なビジネスロジックがないので、ドメイン層はスキップ
インターフェイスを設計するために読んだ技術書まとめ - 自由課題
アーキテクトの(機能面での)主要な仕事の１つに、システムを構成するサブシステム/コンポーネントの境界、つまりインターフェイスを決める、というものがあります。またはそこまで大げさに捉えなくても、例えばライブラリのAPIを設計する、というのは単にプログラミングをする、ということとは少し違う視点が求められるように思います。 案外インターフェイスを考えるという観点での技術書まとめがないような気がしたので、需要があるかわかりませんが関連して読んだ本を紹介しておきます。なお、個人的なキャリア上、C++/Javaが対象です。(色々経験したら随時追加するかも知れません) 何か他にいい本があったらぜひ教えてください。 言語仕様をきちんと知る まずはAPIを設計する対象言語をよく知る、ということは必要であると思います。これだけだと、結果的にプログラミングに精通するということとあまり変わりはないかも知れません。
学ぶ、考える、書き出す。
2023年1月1日 2022年の振り返り 今年は良くも悪くも某国際球技イベントに振り回された年だった。 2022年12月19日 サウナで整ったけど危険性も感じた サウナで整う状態を初体験したけど、体験してみてこれは身体にとって危ないやつだと思った。 2022年11月23日 eslint-plugin-importによってVitestの設定ファイル上でエラーが発生する場合がある vitest と eslint-plugin-import に依存している環境では、vitest.config.ts内で vitest/config をインポートすると Unable to resolve path to module 'vitest/config'. eslint(import/no-unresolved) というエラーが出る場合があります。 2022年8月24日 Next.js + Vercel
microservicesに分割する際に注意するべき5つのこと - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに マーティンファウラーがmicroservicesの記事で、小さな役割をもったサービス群にアプリケーションを分割することを提案しています。 cookpadが、サービスをマイクロサービス群に分割していることの記事が注目を浴びており、最近急速にバズワード化しているように感じます。 バズワード化して、ポイントが損なわれる前にいくつかの注意点をまとめておきます。 1.インフラコストは基本的に増大する microservicesは、今まで単一のアプリケーションコードで行われていたことを複数のサービスサーバーに分割して管理・運営していくこと
続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi
三度の飯よりエラー処理。古橋です。 大変好評をいただいた序章リトライと冪等性のデザインパターンの続編です。 前回はほぼ前置きでしたが、今回は冪等でない操作を冪等にする具体的なテクニックもまとめていきます。 パターン２：エラーを区別してDELETEを冪等にする リソースに常に一意なIDが振られていれば、Deleteを冪等にするのは難しくない。そもそも同じリソースを2度削除することはできない。 一つ注意するべきなのは、削除されたリソースのIDが再利用されるケースでは、Deleteの冪等性は保証されない。例えば、kill -KILL <pid> コマンドはDelete系のAPIと考えられるが、pidは再利用されるので、何度も繰り返すと意図しないプロセスを殺してしまう可能性がある。 一般にIDの生成は非常に難しい問題だが、Deleteに関してのみ言えば再利用されなければいいので、単調増加する整数（
【画像】首都高速道路「箱崎ジャンクション」は複雑な構造すぎて「ヤマタノオロチ」とも呼ばれている : 哲学ニュースnwk
2014年06月02日12:00 【画像】首都高速道路「箱崎ジャンクション」は複雑な構造すぎて「ヤマタノオロチ」とも呼ばれている Tweet 1： ボ ラギノール(愛知県)＠＼(^o^)／：2014/06/01(日) 20:17:03.59 ID:2QPIAmq20.net ＜社会インフラを行く！＞ヤマタノオロチ「箱崎ジャンクション」 東京都中央区にある首都高速道路の「箱崎ジャンクション」。ここは首都圏交通の要衝です。ジャンクションであると同時にインターチェンジであり、 そして案内板のないパーキングエリアまでもが併設されているという、実に複雑な構造になっています。 ジャンクション（JCT）は、日本語で分岐点を意味します。北関東・東北方面につながる6号向島線、千葉方面につながる7号小松川線、 そして神奈川方面につながる9号深川線という3つの自動車の流れが、ここ箱崎ジャンクションに集中し、そし
WHATS - Les actualités les plus partagées !
Le Comité consultatif actuel doit fixer un calendrier précis pour la réouverture de tous les secteurs fermés en Belgique à partir d’avril ou mai, selon Paul Magnette, chef du parti socialiste francophone PS. Prioriser par secteurs La priorité des assouplissements … Depuis le début de la pandémie, les appels des dirigeants politiques du monde entier demandant aux entreprises technologiques de s’att
アーキテクチャ設計に品質特性を使おう - arclamp
アーキテクチャ設計をするうえで重要なのは「利害関係者の合意を得る」ことです。利害関係者全員の要件が全て理解できても、それぞれの要件には必ずトレードオフが存在します。すべて完ぺきに満たすことは不可能なので、トレードオフをバランスよく判断して利害関係者に納得してもらうのがアーキテクトの腕の見せ所です。 このトレードオフを上手に行うために、そのシステムに求められる品質特性を明示し、コミュニケーションの基礎とする必要があります。ざっくりステップを説明すると、以下のようになるでしょうか。 利害関係者にインタビューをして重視しているポイントを聞き出す そのポイントからシステムに求められる品質特性を整理する 整理された品質特性を元に、実際のアーキテクチャの設計を行う 設計されたアーキテクチャを品質特性に照らし合わせて評価を行う 品質特性というのは色々なところで定義がありますが、経産省が公開している「情報
ドメイン駆動設計読んだ - hitode909の日記
ドメイン駆動設計というのはソフトウェア工学のおしゃれな本で，Kindleで買えたので読んだ．ドメインを軸に戦略的に設計しましょうという本．2週間くらいで読めて良い体験できてよかった． ソフトウェアを，ユーザーインタフェース，アプリケーション，ドメイン，インフラストラクチャという4つの層に分けて，一番重要なのがドメイン層で，ドメイン層にアプリケーションが存在し得る理由がある．銀行システムだったら，口座とか利子みたなやつがドメイン層で，口座がよくできてると銀行としてうまくいく．ATMのタッチパネルというのはユーザーインタフェースで，どんなにATM押しやすくても，ドメイン層に，口座という概念がなくて，ただのハッシュだったりすると，銀行を運営して金を儲けるとか，新たな金融商品とか作るのが困難になる．インフラ層は永続化とかするのだけど，インフラ層がいかによくても，意味ないデータを保存していては銀行倒
SSD専用に設計された「ReThinkDB」、ロックもログも使わない新しいリレーショナルデータベースのアーキテクチャ
SSD専用に設計された「ReThinkDB」、ロックもログも使わない新しいリレーショナルデータベースのアーキテクチャ SSDがHDDに代わるストレージとして普及しようとしていることを背景に、SSDに特化したまったく新しいアーキテクチャを備えたリレーショナルデータベースを開発しようとしている企業があります。「ReThinkDB」です。 昨年7月に、PublickeyではReThinkDBの概要を記事「SSDに最適化したデータベース「RethinkDB」、ロックもログも使わずにトランザクション実現」で伝えました。 その記事の中では、ReThinkDBがロックを使わずにトランザクションを実現し、データベース利用中でもスナップショットがとれ、また異常終了しても容易に復帰できる機能を備えている、といったことを紹介しました。 4月に米サンタクララでに行われた「MySQL Conference & Ex
アーキテクチャ設計の難しさについて - arclamp
アーキテクチャについては、以下のパワポを見て頂くとして。 なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423 from yusuke suzuki アーキテクチャ設計を要約すると「"何をやるか"と"どうやるか"のバランスを取る事」となります。 "何をやるか"というのは"システムのミッション"のことであり、ソフトウェア品質モデルで言うところの"利用時の品質"、つまりはシステムのユーザーが何を達成したいのかということです。これは「このシステムが動き出した時、どんな価値を生み出すべきか」を考えることになります。 次に"どうやるか"というのは、2つの話があると思っています。1つめは"静的な構成"としてのどうやるか。2つめは"動的なプロセス"としてのどうやるか。 "静的な構成"というのはクラス構成であり、設定ファイルの構成であり、フレームワークの構成であり、つまり、システ
同期・非同期処理に関するアーキテクチャ - プログラマの思索
同期・非同期処理に関するアーキテクチャで良い記事があったのでメモ。 【元ネタ】 ITシステムで見られるシーケンス データベースコンサルタントのノウハウちょい見せ ダメな設計は、シーケンスが階段状ではなく、一つのオブジェクトに全ての処理を任せる「責任が肥大化したオブジェクト」がある。 特に初心者が、設計を考えずにいきなりプログラムを書いたり、システムを作ってしまう場合によく見られる。 この設計では、スパゲティコードになりやすく、一つのプログラムが千行を超えて保守しにくかったり、スケールアップや性能要件で壁にぶつかる時が多いだろう。 Webシステムは基本は、上記記事の「三角形」シーケンスに相当する。 メッセージを階段の図のように渡して、処理の結果を受け取るイメージ。 オブジェクト指向の権限移譲では、この設計手法がよく使われる。 MVC2モデルと呼ばれるように、Webシステムはオブジェクト指向と
リソースモデリングパターン
Webアプリケーションについて、RESTfulなURL・リソース設計のパターンを見出すことで、 どのパターンかを判断するだけで、既存の Good Practice が適用できる 名前をつけて呼べるようにしたい Railsなどのフレームワークで簡単に適用できるようにしたい ということを目指しています。 ほんとうに役立つか これはパターンと言えるのか もっと他にもある だいぶ粒度がバラバラ 名前の付け方（パターンは名前重要） など、ぜひご意見をください。 パターン Collection & Member Resource パターン Singular (Singleton) Resource パターン Filtered Collection パターン Filtered Subresource パターン Multi-member Resource パターン Partial Resource パター
MOVEは望まれなかった子 - the sea of fertility
なにやらMOVEが話題です。 MVC is dead, it’s time to MOVE on. http://cirw.in/blog/time-to-move-on [翻訳]MVCは死んだ。MOVEするときがきた きしだのはてな http://d.hatena.ne.jp/nowokay/20120704 Twitterで「”MOVEは生まれた瞬間死んだ” って記事まだー？」って騒いでたら「お前が書けよ」の流れだったので息抜きに書きます。息抜きなので図が無いのは勘弁してください。 MOVEが生まれていない理由 この文中ではMOVEが生まれた理由はMVCの問題点に関わるとされており、そのMVCの問題点としてされているのは次の２点です。 MVCではControllerが肥大化する MVCは10年古い技術で設計されていて、最新のプログラミングパラダイムに対応していない。 しかしこの理由のう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェア設計のすすめ
社内システムの構造と設計、実装のはなし
イマドキCSS設計