Submit Search
Upload
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
•
43 likes
•
22,819 views
Yoshitaka Kawashima
Follow
JJUG CCC 2018 Fall #ccc_e3
Read less
Read more
Software
Report
Share
Report
Share
1 of 58
Download now
Download to read offline
Recommended
Atomic Architecture
Atomic Architecture
Yoshitaka Kawashima
すえなみチャンス暑気払い 2019夏で話した、設計要素を分解して理解してみようという話です。 Simplicity makes easy to understand.
ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣
Yoshitaka Kawashima
JaSST Review 2020の発表資料です。
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
更新日時を排除していくことでそこそこのモデルを書けるようになる手法です。
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
第1回 しょぼべん ( http://connpass.com/event/10849/ ) で話しした、イミュータブルデータモデル(世代編)です。
Tackling Complexity
Tackling Complexity
Yoshitaka Kawashima
設計ナイト2022 「トランザクションスクリプト」でのディスカッション枠スライドです。
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?
Yoshitaka Kawashima
アーキ部 #12 「複雑さ」について語り合う会 の参考資料です
エスイーが要件定義でやるべきたったひとつのこと
エスイーが要件定義でやるべきたったひとつのこと
Yoshitaka Kawashima
Recommended
Atomic Architecture
Atomic Architecture
Yoshitaka Kawashima
すえなみチャンス暑気払い 2019夏で話した、設計要素を分解して理解してみようという話です。 Simplicity makes easy to understand.
ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣
Yoshitaka Kawashima
JaSST Review 2020の発表資料です。
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
更新日時を排除していくことでそこそこのモデルを書けるようになる手法です。
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
第1回 しょぼべん ( http://connpass.com/event/10849/ ) で話しした、イミュータブルデータモデル(世代編)です。
Tackling Complexity
Tackling Complexity
Yoshitaka Kawashima
設計ナイト2022 「トランザクションスクリプト」でのディスカッション枠スライドです。
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?
Yoshitaka Kawashima
アーキ部 #12 「複雑さ」について語り合う会 の参考資料です
エスイーが要件定義でやるべきたったひとつのこと
エスイーが要件定義でやるべきたったひとつのこと
Yoshitaka Kawashima
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
Visual Studio Users Community Japan #1 で発表した資料になります。 https://vsuc.connpass.com/event/143114/
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
Yoshitaka Kawashima
アーキ部#13で使ったスライドです。 サンプルコードはこちらです。 https://github.com/kawasima/revisiting-domain-model
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
pospome
devfest tokyo 2017
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
増田 亨
アジャイル札幌 ドメイン駆動設計 基本を理解する
なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?
Yoshitaka Kawashima
受託開発を生業とするものにとって、見積もり根拠を正しく示すことは死活問題だ、という話です。
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
Koichiro Matsuoka
ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 発売記念に、本書の1,2章の内容を中心にDDDの概要について解説する勉強会です。
ソフトウェア開発における『知の高速道路』
ソフトウェア開発における『知の高速道路』
Yoshitaka Kawashima
吉祥寺.pm #26でお話したソフトウェア開発における『知の高速道路』の話です。 将棋や数学とのソレには程遠い。主にサッカーの戦術的ピリオダイゼーションを参考に考えてみました。が結論は、まだありません。
ゲームエンジニアのためのデータベース設計
ゲームエンジニアのためのデータベース設計
sairoutine
GameServerDevelopers Vol.1 https://gsdevelopers.doorkeeper.jp/events/42497
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
2013/04/20 デブサミ 2013 アワード & リバイバル
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料:http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ CQRSはDDDと切り分けて単独でも適用することができるので、DDDについてご存知ない方もご覧いただけます。日本語の文献は意外と少ないので、この辺りの分野に興味がある人の参考になれば幸いです。
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
Mikiya Okuno
理論から学ぶデータベース実践入門読書会スペシャルで発表した資料です。
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
Koichiro Matsuoka
質問への回答(35件)を、ブログにまとめているのでこちらご覧ください https://little-hands.hatenablog.com/entry/2019/08/31/genba_de_ddd 「Mix Leap Study 特別編 - レガシーをぶっつぶせ。現場でDDD! コラボカンファレンス」登壇資料 ブログ:https://little-hands.hatenablog.com/ Twitter:https://twitter.com/little_hand_s 質問箱:https://peing.net/ja/little_hands
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
アプリケーションの分割のアプローチ ●4つのアプローチ - ビジネスファンクション - 動詞/ユースケース - 名詞/リソース - 境界づけられたコンテキスト ● トランザクションの分割 - パイプライン化 (VETRO) - コーディネート (Saga) - 状態更新の非同期化 ( Event History - State Materialize - Domain Specific Query )
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
SQLアンチパターン 26章「とりあえず削除フラグ」 2015/08/31 @ GMO Yours #ronsakucasual https://atnd.org/events/68902
システムダウンのひみつ
システムダウンのひみつ
Yoshitaka Kawashima
吉祥寺.pm #23の発表資料です。 Test Harnessを使って、仕様外のふるまいをテストしましょうというお話です。 https://github.com/kawasima/rodriguez
PostgreSQLアンチパターン
PostgreSQLアンチパターン
Soudai Sone
・OSC徳島 ・PostgreSQLカンファレンス ・JJUG CCC の登壇資料です
Pythonによる黒魔術入門
Pythonによる黒魔術入門
大樹 小倉
Pythonによる(Rubyでも大体適用可能)黒魔術へ入門するための案内書
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
増田 亨
第2シーズンに向けて、設計コースの内容と進め方について、説明会の資料
データモデリング・テクニック
データモデリング・テクニック
Hidekatsu Izuno
データモデリングの方法論について解説資料を作りました。ご意見がありましたら、お願いいたします。Twitter: https://twitter.com/hidekatsu_izuno 以下に移行します。今後はこちらがメインとなります。 https://speakerdeck.com/hidekatsu_izuno/detamoderingutekunituku
とある現場のシステムアーキテクチャ
とある現場のシステムアーキテクチャ
Shinichi Kozake
DevLOVE関西 現場のアーキテクチャの話をしてみませんか? のセッション資料です。
ICHIGAN 参照アーキテクチャ
ICHIGAN 参照アーキテクチャ
Project ICHIGAN
2011/9の中間発表会資料です。 http://www.project-ichigan.jp/20110927
More Related Content
What's hot
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
Visual Studio Users Community Japan #1 で発表した資料になります。 https://vsuc.connpass.com/event/143114/
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
Yoshitaka Kawashima
アーキ部#13で使ったスライドです。 サンプルコードはこちらです。 https://github.com/kawasima/revisiting-domain-model
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
pospome
devfest tokyo 2017
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
増田 亨
アジャイル札幌 ドメイン駆動設計 基本を理解する
なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?
Yoshitaka Kawashima
受託開発を生業とするものにとって、見積もり根拠を正しく示すことは死活問題だ、という話です。
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
Koichiro Matsuoka
ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 発売記念に、本書の1,2章の内容を中心にDDDの概要について解説する勉強会です。
ソフトウェア開発における『知の高速道路』
ソフトウェア開発における『知の高速道路』
Yoshitaka Kawashima
吉祥寺.pm #26でお話したソフトウェア開発における『知の高速道路』の話です。 将棋や数学とのソレには程遠い。主にサッカーの戦術的ピリオダイゼーションを参考に考えてみました。が結論は、まだありません。
ゲームエンジニアのためのデータベース設計
ゲームエンジニアのためのデータベース設計
sairoutine
GameServerDevelopers Vol.1 https://gsdevelopers.doorkeeper.jp/events/42497
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
2013/04/20 デブサミ 2013 アワード & リバイバル
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料:http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ CQRSはDDDと切り分けて単独でも適用することができるので、DDDについてご存知ない方もご覧いただけます。日本語の文献は意外と少ないので、この辺りの分野に興味がある人の参考になれば幸いです。
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
Mikiya Okuno
理論から学ぶデータベース実践入門読書会スペシャルで発表した資料です。
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
Koichiro Matsuoka
質問への回答(35件)を、ブログにまとめているのでこちらご覧ください https://little-hands.hatenablog.com/entry/2019/08/31/genba_de_ddd 「Mix Leap Study 特別編 - レガシーをぶっつぶせ。現場でDDD! コラボカンファレンス」登壇資料 ブログ:https://little-hands.hatenablog.com/ Twitter:https://twitter.com/little_hand_s 質問箱:https://peing.net/ja/little_hands
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
アプリケーションの分割のアプローチ ●4つのアプローチ - ビジネスファンクション - 動詞/ユースケース - 名詞/リソース - 境界づけられたコンテキスト ● トランザクションの分割 - パイプライン化 (VETRO) - コーディネート (Saga) - 状態更新の非同期化 ( Event History - State Materialize - Domain Specific Query )
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
SQLアンチパターン 26章「とりあえず削除フラグ」 2015/08/31 @ GMO Yours #ronsakucasual https://atnd.org/events/68902
システムダウンのひみつ
システムダウンのひみつ
Yoshitaka Kawashima
吉祥寺.pm #23の発表資料です。 Test Harnessを使って、仕様外のふるまいをテストしましょうというお話です。 https://github.com/kawasima/rodriguez
PostgreSQLアンチパターン
PostgreSQLアンチパターン
Soudai Sone
・OSC徳島 ・PostgreSQLカンファレンス ・JJUG CCC の登壇資料です
Pythonによる黒魔術入門
Pythonによる黒魔術入門
大樹 小倉
Pythonによる(Rubyでも大体適用可能)黒魔術へ入門するための案内書
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
増田 亨
第2シーズンに向けて、設計コースの内容と進め方について、説明会の資料
データモデリング・テクニック
データモデリング・テクニック
Hidekatsu Izuno
データモデリングの方法論について解説資料を作りました。ご意見がありましたら、お願いいたします。Twitter: https://twitter.com/hidekatsu_izuno 以下に移行します。今後はこちらがメインとなります。 https://speakerdeck.com/hidekatsu_izuno/detamoderingutekunituku
What's hot
(20)
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
ドメイン駆動設計 基本を理解する
ドメイン駆動設計 基本を理解する
なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ドメイン駆動設計 モデリング_実装入門勉強会_2020.3.8
ソフトウェア開発における『知の高速道路』
ソフトウェア開発における『知の高速道路』
ゲームエンジニアのためのデータベース設計
ゲームエンジニアのためのデータベース設計
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
なぜ、いま リレーショナルモデルなのか(理論から学ぶデータベース実践入門読書会スペシャル)
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
システムダウンのひみつ
システムダウンのひみつ
PostgreSQLアンチパターン
PostgreSQLアンチパターン
Pythonによる黒魔術入門
Pythonによる黒魔術入門
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
データモデリング・テクニック
データモデリング・テクニック
Similar to 思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
とある現場のシステムアーキテクチャ
とある現場のシステムアーキテクチャ
Shinichi Kozake
DevLOVE関西 現場のアーキテクチャの話をしてみませんか? のセッション資料です。
ICHIGAN 参照アーキテクチャ
ICHIGAN 参照アーキテクチャ
Project ICHIGAN
2011/9の中間発表会資料です。 http://www.project-ichigan.jp/20110927
システム運用 (インフラ編)
システム運用 (インフラ編)
Takashi Abe
【18-C-3】システムアーキテクチャ構築の実践手法
【18-C-3】システムアーキテクチャ構築の実践手法
Developers Summit
アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18
Yusuke Suzuki
2018年12月14日に行われたJaSST Review'18(ソフトウェアレビューシンポジウム 2018)での講演「アーキテクチャのレビューについて」の資料です
Information20120312
Information20120312
b-slash
設計について学ぼう (1).pdf
設計について学ぼう (1).pdf
ssuserec9c6a
Flutterの設計について学ぶ資料。状態管理をRiverpod2.0で行い、最近流行りのジェネレーターを使用しました。
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
Yusuke Suzuki
デブサミ2011での講演内容です。
ICHIGANが目指すもの、およびこれまでの歩みのご紹介
ICHIGANが目指すもの、およびこれまでの歩みのご紹介
Project ICHIGAN
2011/9の中間発表会資料です。 http://www.project-ichigan.jp/20110927
設計自動化の話 ~動作合成(導入)編~
設計自動化の話 ~動作合成(導入)編~
HaNoHito
設計自動化の話の導入部分をさらっと解説
システムエンジニア勉強会『入門編』
システムエンジニア勉強会『入門編』
Nobuhito Ikeda
Similar to 思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
(11)
とある現場のシステムアーキテクチャ
とある現場のシステムアーキテクチャ
ICHIGAN 参照アーキテクチャ
ICHIGAN 参照アーキテクチャ
システム運用 (インフラ編)
システム運用 (インフラ編)
【18-C-3】システムアーキテクチャ構築の実践手法
【18-C-3】システムアーキテクチャ構築の実践手法
アーキテクチャのレビューについて - JaSST Review '18
アーキテクチャのレビューについて - JaSST Review '18
Information20120312
Information20120312
設計について学ぼう (1).pdf
設計について学ぼう (1).pdf
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
ICHIGANが目指すもの、およびこれまでの歩みのご紹介
ICHIGANが目指すもの、およびこれまでの歩みのご紹介
設計自動化の話 ~動作合成(導入)編~
設計自動化の話 ~動作合成(導入)編~
システムエンジニア勉強会『入門編』
システムエンジニア勉強会『入門編』
More from Yoshitaka Kawashima
ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?
Yoshitaka Kawashima
アーキ部#15の資料です。
Are Design Patterns Dead?
Are Design Patterns Dead?
Yoshitaka Kawashima
吉祥寺.pm32で話したスライドです。 邦題: デザインパターンは死んだ(のか)?
本番障害に至る病
本番障害に至る病
Yoshitaka Kawashima
吉祥寺.pm #24の発表資料です。
Mavenの真実とウソ
Mavenの真実とウソ
Yoshitaka Kawashima
JJUG CCC 2019 fall g3のセッション資料です。 「ちょっと凝ったことをしようとすると大量のXMLを書かなきゃいけない」「プラグインを並べてもうまく動いてくれない」など、Mavenは誤解され敬遠され、Gradleなどの他のビルドツールにシェアを奪われてきました。 が、依然としてMavenはJavaのデファクトスタンダードなビルドツールに位置づけられており、マスターする価値は十分にあります。そして良く学んでみると、そもそもXMLで過度なカスタマイズしようというのが誤った使い方だったのに気づきます。そこへ至るにも、タスクランナーの延長線上にある他のビルドツールと異なり、Maven独特なライフサイクルとプラグインの関係性もきちんと理解しておかなければなりません。
アンチフラジャイルの世界
アンチフラジャイルの世界
Yoshitaka Kawashima
NoOps Meetup Tokyo #8での発表資料です。
ウォーターフォールとアジャイルのフェアな比較
ウォーターフォールとアジャイルのフェアな比較
Yoshitaka Kawashima
おもにエンタープライズの開発において「アジャイルってどうなの?」という方への説明資料です。
How to find tech books
How to find tech books
Yoshitaka Kawashima
技術書の見つけ方です。
Antifragile Java - Java Day Tokyo 2017 D1-E1
Antifragile Java - Java Day Tokyo 2017 D1-E1
Yoshitaka Kawashima
How to building an antifragile system using Java.
たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力
Yoshitaka Kawashima
2017/2/17のアーキ部の資料です。 異文化理解力に関して思うところをまとめました。
SIerにとっての越境 @ DevLOVE 199
SIerにとっての越境 @ DevLOVE 199
Yoshitaka Kawashima
SIerの方が本質的にオープンにいけると思うのですよ。
Antifragile Clojure
Antifragile Clojure
Yoshitaka Kawashima
nishi-shinju-clojure #0のLTスライドです。
Boilerplate vs Magic
Boilerplate vs Magic
Yoshitaka Kawashima
BoilerplateとMagic論争をStruts1を交えて考えてみました。
既婚プログラマの時間捻出術
既婚プログラマの時間捻出術
Yoshitaka Kawashima
既婚プログラマの時間捻出術です
Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか
Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか
Yoshitaka Kawashima
Java Day Tokyo 2016 のセッション3-Eの資料です。 Java8, Java9の新機能がシステムの設計にどういう影響があるのかを考えてみました。
マイクロフレームワークEnkan(とKotowari)ではじめるREPL駆動開発
マイクロフレームワークEnkan(とKotowari)ではじめるREPL駆動開発
Yoshitaka Kawashima
JJUG CCC 2016 Spring CD-7 のセッションスライドです。
週刊Webサイトのアーキテクチャ
週刊Webサイトのアーキテクチャ
Yoshitaka Kawashima
DevLOVE甲子園 2015 東日本大会 の発表です
キメるClojure
キメるClojure
Yoshitaka Kawashima
みんなでClojureをキメよう!
Seasar conference 2015 sa-compojure
Seasar conference 2015 sa-compojure
Yoshitaka Kawashima
Struts1 Forever
渋谷JVM#1 Immutable時代のプログラミング言語 Clojure
渋谷JVM#1 Immutable時代のプログラミング言語 Clojure
Yoshitaka Kawashima
Clojure
JobStreamerではじめるJavaBatchのクラウド分散実行
JobStreamerではじめるJavaBatchのクラウド分散実行
Yoshitaka Kawashima
JJUG CCC 2015 Spring F-7のセッションです。
More from Yoshitaka Kawashima
(20)
ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?
Are Design Patterns Dead?
Are Design Patterns Dead?
本番障害に至る病
本番障害に至る病
Mavenの真実とウソ
Mavenの真実とウソ
アンチフラジャイルの世界
アンチフラジャイルの世界
ウォーターフォールとアジャイルのフェアな比較
ウォーターフォールとアジャイルのフェアな比較
How to find tech books
How to find tech books
Antifragile Java - Java Day Tokyo 2017 D1-E1
Antifragile Java - Java Day Tokyo 2017 D1-E1
たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力
SIerにとっての越境 @ DevLOVE 199
SIerにとっての越境 @ DevLOVE 199
Antifragile Clojure
Antifragile Clojure
Boilerplate vs Magic
Boilerplate vs Magic
既婚プログラマの時間捻出術
既婚プログラマの時間捻出術
Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか
Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか
マイクロフレームワークEnkan(とKotowari)ではじめるREPL駆動開発
マイクロフレームワークEnkan(とKotowari)ではじめるREPL駆動開発
週刊Webサイトのアーキテクチャ
週刊Webサイトのアーキテクチャ
キメるClojure
キメるClojure
Seasar conference 2015 sa-compojure
Seasar conference 2015 sa-compojure
渋谷JVM#1 Immutable時代のプログラミング言語 Clojure
渋谷JVM#1 Immutable時代のプログラミング言語 Clojure
JobStreamerではじめるJavaBatchのクラウド分散実行
JobStreamerではじめるJavaBatchのクラウド分散実行
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
1.
思考停止しないアーキテクチャ設計しないアーキテクチャ設計アーキテクチャ設計設計 kawasima JJUG CCC 2018
Fall #ccc_e3
2.
What is Software
Architecture ● IEEE1471「コンポーネント、それらの関係や環境、設計やそのコンポーネント、それらの関係や環境、設計やそのそれらの関係や環境、設計やその関係や環境、設計やそのや環境、設計やその環境、それらの関係や環境、設計やその設計やそのや環境、設計やそのその関係や環境、設計やその 進化を左右する原則に具現化されたシステムの基本的な構成」を左右する原則に具現化されたシステムの基本的な構成」左右する原則に具現化されたシステムの基本的な構成」する原則に具現化されたシステムの基本的な構成」原則に具現化されたシステムの基本的な構成」に具現化されたシステムの基本的な構成」具現化を左右する原則に具現化されたシステムの基本的な構成」されたシステムの基本的な構成」システムの基本的な構成」の関係や環境、設計やその基本的な構成」な構成」構成」」 ● Martin Fowler 「コンポーネント、それらの関係や環境、設計やその重要かつ変更が困難な意思決定である」かつ変更が困難な意思決定である」変更が困難な意思決定である」が困難な意思決定である」困難な意思決定である」な構成」意思決定である」である原則に具現化されたシステムの基本的な構成」」 ● Grady Booch 「コンポーネント、それらの関係や環境、設計やそのシステムの基本的な構成」を左右する原則に具現化されたシステムの基本的な構成」形作る重要な設計上の意思決定である原則に具現化されたシステムの基本的な構成」重要かつ変更が困難な意思決定である」な構成」設計やその上の意思決定であの関係や環境、設計やその意思決定である」であ り、それらの関係や環境、設計やそのその関係や環境、設計やその重要かつ変更が困難な意思決定である」性は変更のコストによって測られる」は変更のコストによって測られる」変更が困難な意思決定である」の関係や環境、設計やそのコストに具現化されたシステムの基本的な構成」よって測られる」測られる」られる原則に具現化されたシステムの基本的な構成」」 ● Michael Keeling「コンポーネント、それらの関係や環境、設計やそのソフトウェアが望ましい品質特性や他の性が困難な意思決定である」望ましい品質特性や他の性ましい品質特性や他の性品質特性は変更のコストによって測られる」や環境、設計やその他の性の関係や環境、設計やその性は変更のコストによって測られる」 質を左右する原則に具現化されたシステムの基本的な構成」どうや環境、設計やそのって測られる」達成」して測られる」い品質特性や他の性くかに具現化されたシステムの基本的な構成」つ変更が困難な意思決定である」い品質特性や他の性て測られる」の関係や環境、設計やその重要かつ変更が困難な意思決定である」な構成」設計やその上の意思決定であの関係や環境、設計やその意思 決定である」である原則に具現化されたシステムの基本的な構成」」 Desing It! ● Neal Ford 「コンポーネント、それらの関係や環境、設計やその運用可能になるまで抽象化したもの」 に具現化されたシステムの基本的な構成」な構成」る原則に具現化されたシステムの基本的な構成」まで抽象化を左右する原則に具現化されたシステムの基本的な構成」したシステムの基本的な構成」もの関係や環境、設計やその」 ● Robert C. Martin「コンポーネント、それらの関係や環境、設計やその設計やそのとな構成」に具現化されたシステムの基本的な構成」も違いはない」 い品質特性や他の性は変更のコストによって測られる」な構成」い品質特性や他の性」 Clean Architecture
3.
ソフトウェアが望ましい品質特性や他の性アが望ましい品質特性や他の性ーキテクチャ Is 重要かつ変更が困難な意思決定である」な構成」意思決定である」
4.
Classicalなアーキテクチャ設計設計 Start 操作る重要な設計上の意思決定であ説明 概略の要件の関係や環境、設計やその要かつ変更が困難な意思決定である」件 レガシーシステムの基本的な構成」 新しいシステムしい品質特性や他の性システムの基本的な構成」 システムの基本的な構成」固有のアーキテクチャの関係や環境、設計やそのアが望ましい品質特性や他の性ーキテクチャ ソフトウェアが望ましい品質特性や他の性アが望ましい品質特性や他の性ーキテクチャ 詳細設計やその 実装 奇跡がおきて…が困難な意思決定である」おきて測られる」… Joke
5.
非機能要求からアーキテクチャ設計からアーキテクチャ設計アーキテクチャ設計設計 機能になるまで抽象化したもの」 性は変更のコストによって測られる」 信頼性は変更のコストによって測られる」
使用性は変更のコストによって測られる」 効率性は変更のコストによって測られる」 保守性は変更のコストによって測られる」 移植性は変更のコストによって測られる」 アが望ましい品質特性や他の性ーキテクチャ 設計やその 非機能になるまで抽象化したもの」 要かつ変更が困難な意思決定である」求 (NFR) 品質特性は変更のコストによって測られる」 アが望ましい品質特性や他の性ーキテクチャ パターン
6.
品質特性シナリオシナリオ 成」果物 (Artifact) 環境 (Environment) レスポンス (Response) レスポンス計やその測られる」 (Response Measure) 刺激発生源 (Source of
Stimulus) 刺激 (Stimulus) Software Architecture in Practice より
7.
可用性シナリオのケースケース 成」果物 環境 レスポンス レスポンス計やその測られる」 刺激発生源 刺激 ヘルスチェックヘルスチェック サーバ無応答無応答 プロセス 平常状態 ダウンタイムの基本的な構成」な構成」し 運用が困難な意思決定である」継続できるできる原則に具現化されたシステムの基本的な構成」
8.
平常状態に具現化されたシステムの基本的な構成」おい品質特性や他の性て測られる」、それらの関係や環境、設計やそのヘルスチェックが困難な意思決定である」1回 無応答状態に具現化されたシステムの基本的な構成」な構成」って測られる」も、それらの関係や環境、設計やその その関係や環境、設計やそのサーバ無応答は変更のコストによって測られる」適切に切り離されに具現化されたシステムの基本的な構成」切に切り離されり離されされ サービス全体としてはとして測られる」は変更のコストによって測られる」ダウンタイムの基本的な構成」な構成」しに具現化されたシステムの基本的な構成」 処理継続できるされる原則に具現化されたシステムの基本的な構成」こと 品質特性シナリオシナリオのケース例 Environment Source of
Stimulus Stimulus Artifact Response Measure Response
9.
可用性シナリオのケース戦術 Availability Tactics 異常の関係や環境、設計やその検知 異常状態からの関係や環境、設計やそのリカバ無応答リ
異常状態の関係や環境、設計やその防止 切に切り離されり離されし トランザクション 予測られる」モデル 例外防止 再起動準備と修復と修復 縮退 スペアが望ましい品質特性や他の性 例外 ハンドリング ロールバ無応答ック リトライ デグラデーション シャドウモード 再同期 再起動レベル グレイスフル リスタート ping/echo 監視 ハートビート 例外検知 自己診断
10.
性シナリオ能のケース戦術 Performance Tactics リソース要かつ変更が困難な意思決定である」求の関係や環境、設計やそのコントロール リソースの関係や環境、設計やその管理 リソースを左右する原則に具現化されたシステムの基本的な構成」増やすや環境、設計やそのす 並列化を左右する原則に具現化されたシステムの基本的な構成」する原則に具現化されたシステムの基本的な構成」 計やその算リソースの複数コピーをもつリソースの関係や環境、設計やその複数コピーをもつコピーを左右する原則に具現化されたシステムの基本的な構成」もつ変更が困難な意思決定である」 データの関係や環境、設計やその複数コピーをもつコピーを左右する原則に具現化されたシステムの基本的な構成」もつ変更が困難な意思決定である」 キューサイズを制限するを左右する原則に具現化されたシステムの基本的な構成」制限するする原則に具現化されたシステムの基本的な構成」 リソースを左右する原則に具現化されたシステムの基本的な構成」スケジューリングする原則に具現化されたシステムの基本的な構成」 サンプリングレートを左右する原則に具現化されたシステムの基本的な構成」 コントロールする原則に具現化されたシステムの基本的な構成」 イベントレスポンスを左右する原則に具現化されたシステムの基本的な構成」 制限するする原則に具現化されたシステムの基本的な構成」 イベントに具現化されたシステムの基本的な構成」優先度をつけるを左右する原則に具現化されたシステムの基本的な構成」つ変更が困難な意思決定である」ける原則に具現化されたシステムの基本的な構成」 オーバ無応答ーヘッドを左右する原則に具現化されたシステムの基本的な構成」減らすらす 実行時間を制限するを左右する原則に具現化されたシステムの基本的な構成」制限するする原則に具現化されたシステムの基本的な構成」 リソース効率を左右する原則に具現化されたシステムの基本的な構成」あげる原則に具現化されたシステムの基本的な構成」
11.
品質特性シナリオ間のトレードオフのケーストレードオフ 可 用 効 率 柔 軟 完 全 相 互 運 用 保 守 移 植 信 頼 再 利 用 堅 牢 テ ス ト 使 い品質特性や他の性 勝 手 可用 + + 効率
➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ 柔軟 ➖ ➖ + + + + 完全 ➖ ➖ ➖ ➖ ➖ 相互運用 ➖ + ➖ + 保守 + ➖ + + + 移植 ➖ + + ➖ + + ➖ 信頼 + ➖ + + + + + 再利用 ➖ + ➖ ➖ + 堅牢さ + ➖ + + テスト + ➖ + + + + 使い品質特性や他の性勝手 ➖ + https://msdn.microsoft.com/en-us/library/bb402962.aspx
12.
アーキテクチャ設計パターン タクティクスの関係や環境、設計やそのパッケージである原則に具現化されたシステムの基本的な構成」 ● 責務の割当の関係や環境、設計やその割当 ● 協調のモデルの関係や環境、設計やそのモデル ● データモデル ● リソースの関係や環境、設計やそのコントロール ● アが望ましい品質特性や他の性ーキテクチャ要かつ変更が困難な意思決定である」素間を制限するの関係や環境、設計やそのマッピング ● 束縛時間を制限するの関係や環境、設計やその決定である」 ● テクノロジーの関係や環境、設計やその選択
13.
代表的なアーキテクチャパターンなアーキテクチャ設計パターン ● レイヤード – MVCとかClean Architectureとか ● イベント駆動 ● マイクロカーネル –
Eclipse ● マイクロサービス ● スペースベース – GemFireとかCoherenceとか Software Architecture Patterns より
14.
アーキテクチャ設計パターン間のトレードオフのケース トレードオフ レイヤード イベント 駆動 マイクロ カーネル マイクロ サービス スペース ベース アが望ましい品質特性や他の性ジリティ ➖ +
+ + + デプロイ 容易性は変更のコストによって測られる」 ➖ + + + + テスト 容易性は変更のコストによって測られる」 + ➖ + + ➖ 性は変更のコストによって測られる」能になるまで抽象化したもの」 ➖ + + ➖ + スケーラビ リティ ➖ + ➖ + + 開発 しや環境、設計やそのすさ + ➖ ➖ + ➖
15.
アが望ましい品質特性や他の性ーキテクチャ設計やそのに具現化されたシステムの基本的な構成」 どれだけ時間を制限するを左右する原則に具現化されたシステムの基本的な構成」かける原則に具現化されたシステムの基本的な構成」か?
16.
アーキテクチャ設計設計にどれくらアーキテクチャ設計いアーキテクチャ設計時間のトレードオフをかけるか プロジェクトの関係や環境、設計やその時間を制限する = 開発時間を制限する + アが望ましい品質特性や他の性ーキテクチャとリスク削減らす時間を制限する +
や環境、設計やそのり直しの時間しの関係や環境、設計やその時間を制限する Making Software, How Much Architecting Is Enough?
17.
コード規模によってによって パーセンテージは変わるは変わる変わるわる
18.
アが望ましい品質特性や他の性ーキテクチャ設計やそのが困難な意思決定である」 十分かどう評価するかかどう評価するかする原則に具現化されたシステムの基本的な構成」か?
19.
Rubrics 品質特性は変更のコストによって測られる」 シナリオ Rating 可用性は変更のコストによって測られる」
検索インデックスが死んでいていも、必要インデックスが困難な意思決定である」死んでいていも、必要んでい品質特性や他の性て測られる」い品質特性や他の性も、それらの関係や環境、設計やその必要かつ変更が困難な意思決定である」 最低限するの関係や環境、設計やそのレスポンスを左右する原則に具現化されたシステムの基本的な構成」返せるせる原則に具現化されたシステムの基本的な構成」 可用性は変更のコストによって測られる」 メンテナンス中を除いて、常にレスポンスを左右する原則に具現化されたシステムの基本的な構成」除いて、常にレスポンスい品質特性や他の性て測られる」、それらの関係や環境、設計やその常に具現化されたシステムの基本的な構成」レスポンス を左右する原則に具現化されたシステムの基本的な構成」返せるすことが困難な意思決定である」できる原則に具現化されたシステムの基本的な構成」 性は変更のコストによって測られる」能になるまで抽象化したもの」 平均的な構成」な構成」負荷状態で、それらの関係や環境、設計やその3秒以内にレスポンスに具現化されたシステムの基本的な構成」レスポンス が困難な意思決定である」返せるすことが困難な意思決定である」できる原則に具現化されたシステムの基本的な構成」 スケーラビ リティ 向こうこう5年間を制限するで、それらの関係や環境、設計やその毎年20%ずつ変更が困難な意思決定である」データ量がが困難な意思決定である」 増やす加していくデータを扱うことができるして測られる」い品質特性や他の性くデータを左右する原則に具現化されたシステムの基本的な構成」扱うことができるうことが困難な意思決定である」できる原則に具現化されたシステムの基本的な構成」 … … 品質特性は変更のコストによって測られる」シナリオを左右する原則に具現化されたシステムの基本的な構成」使って測られる」、それらの関係や環境、設計やその設計やそのしたシステムの基本的な構成」アが望ましい品質特性や他の性ーキテク チャが困難な意思決定である」、それらの関係や環境、設計やそのそれを左右する原則に具現化されたシステムの基本的な構成」満たすか評価する。たシステムの基本的な構成」すか評価するかする原則に具現化されたシステムの基本的な構成」。
20.
Ratingのケース基準 ● 1 = シナリオの関係や環境、設計やその期待にそぐわない、または評価に値しに具現化されたシステムの基本的な構成」そぐわな構成」い品質特性や他の性、それらの関係や環境、設計やそのまたシステムの基本的な構成」は変更のコストによって測られる」評価するかに具現化されたシステムの基本的な構成」値しし な構成」い品質特性や他の性。 ● 2
= 部分かどう評価するか的な構成」に具現化されたシステムの基本的な構成」シナリオを左右する原則に具現化されたシステムの基本的な構成」満たすか評価する。たシステムの基本的な構成」して測られる」い品質特性や他の性る原則に具現化されたシステムの基本的な構成」。またシステムの基本的な構成」は変更のコストによって測られる」シナリ オは変更のコストによって測られる」満たすか評価する。たシステムの基本的な構成」せて測られる」い品質特性や他の性る原則に具現化されたシステムの基本的な構成」が困難な意思決定である」、それらの関係や環境、設計やその受け入れがたい高リスクや技術け入れがたい高リスクや技術れが困難な意思決定である」たシステムの基本的な構成」い品質特性や他の性高リスクや技術リスクや環境、設計やその技術 的な構成」負債、それらの関係や環境、設計やそのコスト超過がある。が困難な意思決定である」ある原則に具現化されたシステムの基本的な構成」。 ● 3 = シナリオを左右する原則に具現化されたシステムの基本的な構成」満たすか評価する。たシステムの基本的な構成」して測られる」おり、それらの関係や環境、設計やその許容できる原則に具現化されたシステムの基本的な構成」リスク、それらの関係や環境、設計やその技 術的な構成」負債、それらの関係や環境、設計やそのコストである原則に具現化されたシステムの基本的な構成」。 ● 4 = シナリオを左右する原則に具現化されたシステムの基本的な構成」満たすか評価する。たシステムの基本的な構成」して測られる」おり、それらの関係や環境、設計やそのリスクや環境、設計やその技術的な構成」負債が困難な意思決定である」 ほとんどな構成」い品質特性や他の性(まったシステムの基本的な構成」くな構成」い品質特性や他の性)、それらの関係や環境、設計やそのまたシステムの基本的な構成」予算リソースの複数コピーをもつ内にレスポンスに具現化されたシステムの基本的な構成」収まってまって測られる」 い品質特性や他の性る原則に具現化されたシステムの基本的な構成」。
21.
課題をいろんな視点からみるをいアーキテクチャ設計ろんな視点からみるからアーキテクチャ設計みる Architectural Issues Rainbow ● リスク:
潜在的な構成」な構成」問題 ● 分かどう評価するかかって測られる」な構成」い品質特性や他の性もの関係や環境、設計やその ● 問題 すでに具現化されたシステムの基本的な構成」顕在化を左右する原則に具現化されたシステムの基本的な構成」して測られる」い品質特性や他の性る原則に具現化されたシステムの基本的な構成」良くないことくな構成」い品質特性や他の性こと ● 理解度をつけるの関係や環境、設計やそのギャップ ● 当初アーキテクチャ思想の崩壊アが望ましい品質特性や他の性ーキテクチャ思想の崩壊の関係や環境、設計やその崩壊 ● ビジネス環境の関係や環境、設計やその変化を左右する原則に具現化されたシステムの基本的な構成」
22.
アが望ましい品質特性や他の性ーキテクチャ設計やそのを左右する原則に具現化されたシステムの基本的な構成」 どう記録しメンテしていくかしメンテして測られる」い品質特性や他の性くか?
23.
Architecture Decision Records (ADR) ソースリポジトリと同じところに具現化されたシステムの基本的な構成」、それらの関係や環境、設計やその1つ変更が困難な意思決定である」の関係や環境、設計やその意思決定である」 単位に、に具現化されたシステムの基本的な構成」、それらの関係や環境、設計やその1つ変更が困難な意思決定である」パターン記述に似た感じで記録する。に具現化されたシステムの基本的な構成」似た感じで記録する。たシステムの基本的な構成」感じで記録する。じで記録しメンテしていくかする原則に具現化されたシステムの基本的な構成」。 構成」 ● タイトル ● ステータス ● コンテキスト ● 選択肢
/ 選択肢の関係や環境、設計やそのメリデメ ● 決定である」事項 https://gist.github.com/kawasima/e325eda1c910d2abc5fb5f69d6a692e2
24.
25.
26.
ADRのケース例 拙作る重要な設計上の意思決定であBouncrの関係や環境、設計やその次期バ無応答ージョンに具現化されたシステムの基本的な構成」関して測られる」
27.
それでも発生する原則に具現化されたシステムの基本的な構成」 アが望ましい品質特性や他の性ーキテクチャ上の意思決定であの関係や環境、設計やその 考慮漏れれ 設計やその上の意思決定であ重要かつ変更が困難な意思決定である」な構成」意思決定である」
28.
「コンポーネント、それらの関係や環境、設計やその教科書どおりのどおりの関係や環境、設計やその プロセスを左右する原則に具現化されたシステムの基本的な構成」踏んでるからんでる原則に具現化されたシステムの基本的な構成」から 大丈夫」 で満たすか評価する。足しないしな構成」い品質特性や他の性
29.
The Patterns of
Stop Thinking ● 限する界意識の思考停止の関係や環境、設計やその思考停止 ● 無意識の思考停止の関係や環境、設計やその思考停止 ● 特別意識の思考停止の関係や環境、設計やその思考停止 ● ひきこもりの関係や環境、設計やその思考停止 ● 卑屈の思考停止の関係や環境、設計やその思考停止 ● 責任転嫁の思考停止の関係や環境、設計やその思考停止 ● 子供扱うことができるい品質特性や他の性の関係や環境、設計やその思考停止 https://anond.hatelabo.jp/20150805115616 タイトルの回収用の回収用回収用
30.
機能になるまで抽象化したもの」 要かつ変更が困難な意思決定である」求に具現化されたシステムの基本的な構成」含まれるまれる原則に具現化されたシステムの基本的な構成」 アが望ましい品質特性や他の性ーキテクチャ要かつ変更が困難な意思決定である」求
31.
Architectural Significant Requirements (ASR) 要かつ変更が困難な意思決定である」求 設計やその 機能になるまで抽象化したもの」
要かつ変更が困難な意思決定である」求 非機能になるまで抽象化したもの」 要かつ変更が困難な意思決定である」求(NFR) 機能になるまで抽象化したもの」 設計やその アが望ましい品質特性や他の性ーキテクチャ設計やその アが望ましい品質特性や他の性ーキテクチャ要かつ変更が困難な意思決定である」求 (ASR)
32.
機能になるまで抽象化したもの」 要かつ変更が困難な意思決定である」求に具現化されたシステムの基本的な構成」も 設計やその上の意思決定であの関係や環境、設計やその重要かつ変更が困難な意思決定である」な構成」意思決定である」が困難な意思決定である」 含まれるまれる原則に具現化されたシステムの基本的な構成」
33.
カテゴリ毎の件数表示のケース件数表示 ドリルダウンの関係や環境、設計やその検索インデックスが死んでいていも、必要導線においに具現化されたシステムの基本的な構成」おい品質特性や他の性 て測られる」、それらの関係や環境、設計やそのカテゴリごとに具現化されたシステムの基本的な構成」ヒットする原則に具現化されたシステムの基本的な構成」検 索インデックスが死んでいていも、必要結果を左右する原則に具現化されたシステムの基本的な構成」表示することで、カスタする原則に具現化されたシステムの基本的な構成」ことで、それらの関係や環境、設計やそのカスタ マが困難な意思決定である」その関係や環境、設計やそのリンクを左右する原則に具現化されたシステムの基本的な構成」押すす/押すさな構成」い品質特性や他の性 動機を左右する原則に具現化されたシステムの基本的な構成」 強めることができる。める原則に具現化されたシステムの基本的な構成」ことが困難な意思決定である」できる原則に具現化されたシステムの基本的な構成」。
34.
判断ポイントポイント ● 0件の関係や環境、設計やそのカテゴリを左右する原則に具現化されたシステムの基本的な構成」表示することで、カスタする原則に具現化されたシステムの基本的な構成」か否かか ● 件数コピーをもつの関係や環境、設計やその正確さをどこまで求めるかさを左右する原則に具現化されたシステムの基本的な構成」どこまで求める原則に具現化されたシステムの基本的な構成」か? ● 件数コピーをもつの関係や環境、設計やそのフレッシュさを左右する原則に具現化されたシステムの基本的な構成」どこまで求める原則に具現化されたシステムの基本的な構成」か? ● 複数コピーをもつの関係や環境、設計やその検索インデックスが死んでいていも、必要条件が困難な意思決定である」選択されたシステムの基本的な構成」ときに具現化されたシステムの基本的な構成」追従してして測られる」 ヒットしたシステムの基本的な構成」件数コピーをもつに具現化されたシステムの基本的な構成」書どおりのき換えるかえる原則に具現化されたシステムの基本的な構成」か?
35.
モデル例例 name lower upper SALARY_RANGES id title salary JOB_DESCRIPTIONS id title salary 1
PM 342 2 Programmer 442 3 DBA 388 4 PM 247 5 Programmer 790 6 Programmer 678 name lower upper 200万円 200 299 300万円 300 399 400万円 400 499 500万円 500 599 600万円 600 699 700万円 700 799
36.
SQLを書いてみるいアーキテクチャ設計てみる 求人(job_postings)テーブルの関係や環境、設計やそのFULL SCANとな構成」り コストの関係や環境、設計やその高リスクや技術い品質特性や他の性検索インデックスが死んでいていも、必要とな構成」る原則に具現化されたシステムの基本的な構成」。
37.
検索エンジンを使うエンジは変わるンを使うう Elasticsearchの関係や環境、設計やそのAggregationを左右する原則に具現化されたシステムの基本的な構成」使ったシステムの基本的な構成」例
38.
複数コピーをもつの関係や環境、設計やその検索インデックスが死んでいていも、必要カテゴリの関係や環境、設計やそのサマリが困難な意思決定である」 1クエリで高リスクや技術速にできるに具現化されたシステムの基本的な構成」できる原則に具現化されたシステムの基本的な構成」
39.
リザル例トキャ設計ッシュ ● A. 定である」期的な構成」に具現化されたシステムの基本的な構成」集計やそのして測られる」保存しておくして測られる」おく 集計やその用の関係や環境、設計やそのテーブルを左右する原則に具現化されたシステムの基本的な構成」作る重要な設計上の意思決定であって測られる」、それらの関係や環境、設計やその定である」期的な構成」に具現化されたシステムの基本的な構成」カテゴリごとの関係や環境、設計やその集計やそのします。 ● B. クエリの関係や環境、設計やそのリザルトキャッシュ O/Rマッパーや環境、設計やそのデータベース、それらの関係や環境、設計やその検索インデックスが死んでいていも、必要エンジンの関係や環境、設計やそのリザルトキャッシュの関係や環境、設計やその機 能になるまで抽象化したもの」
を左右する原則に具現化されたシステムの基本的な構成」使って測られる」、それらの関係や環境、設計やそのキャッシュさせる原則に具現化されたシステムの基本的な構成」ことが困難な意思決定である」できます (リザルトキャッシュ の関係や環境、設計やその詳細は変更のコストによって測られる」別章にてに具現化されたシステムの基本的な構成」て測られる」)。大抵の場合、透過的にキャッシュできるので、の関係や環境、設計やその場合、それらの関係や環境、設計やその透過がある。的な構成」に具現化されたシステムの基本的な構成」キャッシュできる原則に具現化されたシステムの基本的な構成」の関係や環境、設計やそので、それらの関係や環境、設計やその コードが困難な意思決定である」シンプルに具現化されたシステムの基本的な構成」な構成」り、それらの関係や環境、設計やその特別な構成」ミドルウェアが望ましい品質特性や他の性や環境、設計やその設計やそのが困難な意思決定である」必要かつ変更が困難な意思決定である」でな構成」い品質特性や他の性こ とが困難な意思決定である」メリットです。が困難な意思決定である」、それらの関係や環境、設計やその結局集計やそのの関係や環境、設計やそのクエリが困難な意思決定である」重い品質特性や他の性の関係や環境、設計やそのであれば、それらの関係や環境、設計やそのキャッ シュ有のアーキテクチャ効期限する切に切り離されれの関係や環境、設計やその際のリクエストは遅くなってしまうので、 そういの関係や環境、設計やそのリクエストは変更のコストによって測られる」遅くなってしまうので、 そういくな構成」って測られる」しまうの関係や環境、設計やそので、それらの関係や環境、設計やその そうい品質特性や他の性 うケースを左右する原則に具現化されたシステムの基本的な構成」許容できな構成」い品質特性や他の性の関係や環境、設計やそのであれば、それらの関係や環境、設計やそのAの関係や環境、設計やその定である」期集計やそのに具現化されたシステムの基本的な構成」して測られる」おくの関係や環境、設計やそのが困難な意思決定である」無難な意思決定である」 です。 とは変更のコストによって測られる」い品質特性や他の性え、それらの関係や環境、設計やそのそれでもコスト高リスクや技術い品質特性や他の性場合は変更のコストによって測られる」…
40.
デグラデーション 負荷の関係や環境、設計やその高リスクや技術い品質特性や他の性ときや環境、設計やその、それらの関係や環境、設計やそのキャッシュの関係や環境、設計やその仕組みが停止していみが困難な意思決定である」停止して測られる」い品質特性や他の性 る原則に具現化されたシステムの基本的な構成」場合、それらの関係や環境、設計やその件数コピーをもつの関係や環境、設計やそのみ出さなくするようにデグラデーショさな構成」くする原則に具現化されたシステムの基本的な構成」ように具現化されたシステムの基本的な構成」デグラデーショ ンさせる原則に具現化されたシステムの基本的な構成」設計やそのを左右する原則に具現化されたシステムの基本的な構成」して測られる」おくと、それらの関係や環境、設計やそのサービス全体としてはの関係や環境、設計やそのダウンを左右する原則に具現化されたシステムの基本的な構成」 防ぐことが困難な意思決定である」できます。 例えばカテゴリの関係や環境、設計やそのみを左右する原則に具現化されたシステムの基本的な構成」以下のようなの関係や環境、設計やそのような構成」JSONファイルに具現化されたシステムの基本的な構成」出さなくするようにデグラデーショ 力しておいて、して測られる」おい品質特性や他の性て測られる」、それらの関係や環境、設計やそのHTMLを左右する原則に具現化されたシステムの基本的な構成」レンダリングする原則に具現化されたシステムの基本的な構成」際のリクエストは遅くなってしまうので、 そういに具現化されたシステムの基本的な構成」は変更のコストによって測られる」、それらの関係や環境、設計やその 取 得した件数をマージします。件数が取得できなけれしたシステムの基本的な構成」件数コピーをもつを左右する原則に具現化されたシステムの基本的な構成」マージします。件数コピーをもつが困難な意思決定である」取得した件数をマージします。件数が取得できなけれできな構成」けれ ば、それらの関係や環境、設計やそのカテゴリの関係や環境、設計やそのみ表示することで、カスタします。
41.
アーキテクチャ設計設計した気分になるのを防ぐ気分になるのを防ぐになるのケースを防ぐぐ NFRからの関係や環境、設計やそのアが望ましい品質特性や他の性プローチ 平常状態でレスポンス3秒以内にレスポンスに具現化されたシステムの基本的な構成」しな構成」きゃい品質特性や他の性けな構成」い品質特性や他の性 →RDBMSじゃ無理な構成」んじゃな構成」い品質特性や他の性? →キャッシュの関係や環境、設計やその仕組みが停止していみつ変更が困難な意思決定である」くろう →な構成」んか性は変更のコストによって測られる」能になるまで抽象化したもの」 でな構成」さそうな構成」ところは変更のコストによって測られる」キャッシュ機構用意 したシステムの基本的な構成」んで使って測られる」ください品質特性や他の性。 機能になるまで抽象化したもの」 要かつ変更が困難な意思決定である」求パターン→ASRの関係や環境、設計やそのアが望ましい品質特性や他の性プローチ 平常状態でレスポンス3秒以内にレスポンスに具現化されたシステムの基本的な構成」しな構成」きゃい品質特性や他の性けな構成」い品質特性や他の性 →どうい品質特性や他の性う機能になるまで抽象化したもの」
でおきる原則に具現化されたシステムの基本的な構成」の関係や環境、設計やそのよ? →検索インデックスが死んでいていも、必要条件の関係や環境、設計やその「コンポーネント、それらの関係や環境、設計やそのカテゴリ毎の関係や環境、設計やその件数コピーをもつ表示することで、カスタ」って測られる」性は変更のコストによって測られる」能になるまで抽象化したもの」 インパクト大きそうよ →まさに具現化されたシステムの基本的な構成」そうい品質特性や他の性うところで、それらの関係や環境、設計やその検索インデックスが死んでいていも、必要エンジンとキャッシュって測られる」使うの関係や環境、設計やそのね 何が言いたいかというとが困難な意思決定である」言いたいかというとい品質特性や他の性たシステムの基本的な構成」い品質特性や他の性かとい品質特性や他の性うと
42.
インフォメーション こうい品質特性や他の性う機能になるまで抽象化したもの」 要かつ変更が困難な意思決定である」求から導かれる原則に具現化されたシステムの基本的な構成」 アが望ましい品質特性や他の性ーキテクチャ要かつ変更が困難な意思決定である」求の関係や環境、設計やそのパターンを左右する原則に具現化されたシステムの基本的な構成」 「コンポーネント、それらの関係や環境、設計やそのアが望ましい品質特性や他の性ーキテクチャ大全」 として測られる」執筆中を除いて、常にレスポンスです
43.
柔軟さとテスト可能になるまで抽象化したもの」 性は変更のコストによって測られる」の関係や環境、設計やその トレードオフ
44.
例題をいろんな視点からみる: ETCのケース割引 割引には以下の適用要件があります。に具現化されたシステムの基本的な構成」は変更のコストによって測られる」以下のようなの関係や環境、設計やその適用要かつ変更が困難な意思決定である」件が困難な意思決定である」あります。 ● 平日朝夕割引には以下の適用要件があります。 – 平日「コンポーネント、それらの関係や環境、設計やその朝:6時〜9時」、それらの関係や環境、設計やその「コンポーネント、それらの関係や環境、設計やその夕:17時〜20時」 –
地方部 – 当月の利用回数がの関係や環境、設計やその利用回数コピーをもつが困難な意思決定である」5回〜9回 30%割引には以下の適用要件があります。、それらの関係や環境、設計やその10回以上の意思決定であ 50%割引には以下の適用要件があります。 ● 休日割引には以下の適用要件があります。 – 普通車、それらの関係や環境、設計やその軽自動車等(二輪車)限する定である」 – 土曜・日曜・祝日 – 地方部 – 30%割引には以下の適用要件があります。 ● 深夜割引には以下の適用要件があります。 – すべて測られる」の関係や環境、設計やその車種 – 毎日0〜4時 – 30%割引には以下の適用要件があります。
45.
まれによく見る柔軟な実装る柔軟な実装な実装 割引には以下の適用要件があります。ルール明細ID 割引には以下の適用要件があります。ルールID テーブル名 カラムの基本的な構成」名 値し 範囲From 範囲To 割引には以下の適用要件があります。ルール明細 割引には以下の適用要件があります。ルールID 割引には以下の適用要件があります。ルール名称 割引には以下の適用要件があります。率 割引には以下の適用要件があります。ルール
46.
割引には以下の適用要件があります。ルー ル明細ID 割引には以下の適用要件があります。ルー ルID テーブル 名 カラムの基本的な構成」名 値し 範囲 1
1 DRIVE_R EC ENTERED _AT 6−9,17- 20 2 1 DRIVE_R EC AREA RURAL 3 1 USE_SUM MARY COUNT 5-9 4 2 DRIVE_R EC ENTERED _AT 5 2 DRIVE_R EC AREA RURAL 6 2 USE_SUM MARY COUNT 10- ルールテーブルを左右する原則に具現化されたシステムの基本的な構成」メンテする原則に具現化されたシステムの基本的な構成」だけで、それらの関係や環境、設計やそのルールを左右する原則に具現化されたシステムの基本的な構成」追加していくデータを扱うことができる・変更が困難な意思決定である」できる原則に具現化されたシステムの基本的な構成」ぜ…(^o^)o^o^))
47.
この関係や環境、設計やその目論見はだいたい上手く行かずは変更のコストによって測られる」だい品質特性や他の性たシステムの基本的な構成」い品質特性や他の性上の意思決定であ手く行かず 「コンポーネント、それらの関係や環境、設計やそのルール詳細テーブルの関係や環境、設計やそのカラムの基本的な構成」追加していくデータを扱うことができる」 「コンポーネント、それらの関係や環境、設計やその予期しな構成」い品質特性や他の性データパターンで不具合」 な構成」ど発生する原則に具現化されたシステムの基本的な構成」ことに具現化されたシステムの基本的な構成」…
48.
適度な柔軟さな柔軟な実装さ(インタフェース)
49.
適度な柔軟さな柔軟な実装さ(実装)
50.
適度な柔軟さな柔軟な実装さ(実装)
51.
柔軟な実装すぎる実装かどうかのケース判断ポイント 設計やそのしたシステムの基本的な構成」内にレスポンス容で保証するデータパターンをする原則に具現化されたシステムの基本的な構成」データパターンを左右する原則に具現化されたシステムの基本的な構成」 網羅したテストケースが作れるかしたシステムの基本的な構成」テストケースが困難な意思決定である」作る重要な設計上の意思決定であれる原則に具現化されたシステムの基本的な構成」か? 最初アーキテクチャ思想の崩壊の関係や環境、設計やその「コンポーネント、それらの関係や環境、設計やその柔軟すぎる原則に具現化されたシステムの基本的な構成」設計やその例」だと、それらの関係や環境、設計やその設計やその上の意思決定であ許容(≠現在の関係や環境、設計やその業務の割当上の意思決定であ)されて測られる」い品質特性や他の性る原則に具現化されたシステムの基本的な構成」 データの関係や環境、設計やその組みが停止していみ合わせに具現化されたシステムの基本的な構成」対してテスト仕切るのは困難して測られる」テスト仕切に切り離される原則に具現化されたシステムの基本的な構成」の関係や環境、設計やそのは変更のコストによって測られる」困難な意思決定である」
52.
Architectural Issues Rainbow 「コンポーネント、それらの関係や環境、設計やその当初アーキテクチャ思想の崩壊アが望ましい品質特性や他の性ーキテクチャ思想の崩壊の関係や環境、設計やその崩壊」 「コンポーネント、それらの関係や環境、設計やそのビジネス環境の関係や環境、設計やその変化を左右する原則に具現化されたシステムの基本的な構成」」 との関係や環境、設計やその闘いい品質特性や他の性
53.
当初の思想/環境とのズレのケース思想/環境とのズレとのケースズレ ● 緊急リリース間に合わない、テーブル定義にまリリース間を制限するに具現化されたシステムの基本的な構成」合わな構成」い品質特性や他の性、それらの関係や環境、設計やそのテーブル定である」義にまに具現化されたシステムの基本的な構成」ま で手を左右する原則に具現化されたシステムの基本的な構成」入れがたい高リスクや技術れる原則に具現化されたシステムの基本的な構成」余裕がない。が困難な意思決定である」な構成」い品質特性や他の性。 ● 相手先システムの基本的な構成」も含まれるめたシステムの基本的な構成」インタフェース修正を左右する原則に具現化されたシステムの基本的な構成」 したシステムの基本的な構成」方が困難な意思決定である」本当は変更のコストによって測られる」良くないことい品質特性や他の性んだけど、それらの関係や環境、設計やその向こうこうの関係や環境、設計やその開発体としては 制を左右する原則に具現化されたシステムの基本的な構成」考える原則に具現化されたシステムの基本的な構成」と… ● 構築時は変更のコストによって測られる」開発スピード最優先だったシステムの基本的な構成」が困難な意思決定である」、それらの関係や環境、設計やその今は可は変更のコストによって測られる」可 用性は変更のコストによって測られる」が困難な意思決定である」一番大事 溜まっていっても仕方のない類のまって測られる」い品質特性や他の性って測られる」も仕方の関係や環境、設計やそのな構成」い品質特性や他の性類のの関係や環境、設計やその 技術的な構成」負債
54.
技術的なアーキテクチャパターン負債バジェットバジは変わるェット 信頼性は変更のコストによって測られる」 機能になるまで抽象化したもの」 開発 技術的な構成」負債返せる済
機能になるまで抽象化したもの」 開発 SRE Architect トレードオフ トレードオフ WolfChief Inc.社 提唱
55.
技術的なアーキテクチャパターン負債バジェットを金額換算する ① リスク顕在化を左右する原則に具現化されたシステムの基本的な構成」確さをどこまで求めるか率 ×
発生したシステムの基本的な構成」ときの関係や環境、設計やその対してテスト仕切るのは困難応費用 = 評価するか額 ② 対してテスト仕切るのは困難処したシステムの基本的な構成」ときの関係や環境、設計やそのリスク顕在化を左右する原則に具現化されたシステムの基本的な構成」確さをどこまで求めるか率 × 発生したシステムの基本的な構成」ときの関係や環境、設計やその対してテスト仕切るのは困難応費用 = 対してテスト仕切るのは困難処済みの関係や環境、設計やその評価するか額 ③ 対してテスト仕切るのは困難処費用 実際のリクエストは遅くなってしまうので、 そういは変更のコストによって測られる」顕在化を左右する原則に具現化されたシステムの基本的な構成」確さをどこまで求めるか率が困難な意思決定である」時間を制限するとともに具現化されたシステムの基本的な構成」変化を左右する原則に具現化されたシステムの基本的な構成」する原則に具現化されたシステムの基本的な構成」 ① と ②+③を左右する原則に具現化されたシステムの基本的な構成」比較するする原則に具現化されたシステムの基本的な構成」
56.
機能になるまで抽象化したもの」 開発時間を制限する 技術的な構成」負債 返せる済時間を制限する 例)技術的な構成」負債リスト (時価するか ①-(②+③)) $500/月の利用回数が
対してテスト仕切るのは困難応不要かつ変更が困難な意思決定である」の関係や環境、設計やそのログが困難な意思決定である」 監視ログに具現化されたシステムの基本的な構成」メチャ出さなくするようにデグラデーショる原則に具現化されたシステムの基本的な構成」 $400/月の利用回数が 請求一覧のの関係や環境、設計やそのSQLが困難な意思決定である」徐々にに具現化されたシステムの基本的な構成」 遅くなってしまうので、 そういくな構成」って測られる」きて測られる」い品質特性や他の性る原則に具現化されたシステムの基本的な構成」 ・・・・・・ 開 発 時 間を制限する 全 体としては 技術的な構成」負債時価するか総額と機能になるまで抽象化したもの」 開発に具現化されたシステムの基本的な構成」よる原則に具現化されたシステムの基本的な構成」利益増やすとを左右する原則に具現化されたシステムの基本的な構成」 比較するして測られる」、それらの関係や環境、設計やその時間を制限する比を左右する原則に具現化されたシステムの基本的な構成」決める原則に具現化されたシステムの基本的な構成」 技術的な構成」負債リストの関係や環境、設計やその時価するか額高リスクや技術い品質特性や他の性もの関係や環境、設計やそのから 投入れがたい高リスクや技術して測られる」い品質特性や他の性く
57.
現代においてに具現化されたシステムの基本的な構成」おい品質特性や他の性て測られる」 アが望ましい品質特性や他の性ーキテクチャ設計やそのは変更のコストによって測られる」 終わりのない仕事であるわりの関係や環境、設計やそのな構成」い品質特性や他の性仕事である原則に具現化されたシステムの基本的な構成」
58.
参考文献 Software Architecture Patterns 代において表的な構成」な構成」アが望ましい品質特性や他の性ーキテクチャの関係や環境、設計やそのパターンとそれらの関係や環境、設計やその品質 特性は変更のコストによって測られる」ごとの関係や環境、設計やそのメリット、それらの関係や環境、設計やそのデメリットが困難な意思決定である」簡潔にまとまっに具現化されたシステムの基本的な構成」まとまっ て測られる」い品質特性や他の性る原則に具現化されたシステムの基本的な構成」。これ1冊でアーキテクチャ史の語り部に。でアが望ましい品質特性や他の性ーキテクチャ史の語り部に。の関係や環境、設計やその語り部に。り部に具現化されたシステムの基本的な構成」。 Software
Architecture in Practice (3rd) 現代においてソフトウェアが望ましい品質特性や他の性アが望ましい品質特性や他の性ーキテクチャ設計やそのに具現化されたシステムの基本的な構成」おける原則に具現化されたシステムの基本的な構成」教科書どおりの 的な構成」な構成」存しておく在。アが望ましい品質特性や他の性ーキテクチャ設計やそのの関係や環境、設計やそのプロセスや環境、設計やそのワーク ショップの関係や環境、設計やそのや環境、設計やそのり方まで幅広く学べ、これを読まずしてく学べ、これを読まずしてべ、それらの関係や環境、設計やそのこれを左右する原則に具現化されたシステムの基本的な構成」読まずしてまずして測られる」 アが望ましい品質特性や他の性ーキテクチャ設計やそのが困難な意思決定である」できる原則に具現化されたシステムの基本的な構成」か! Design It! Software Architecture in Practiceを左右する原則に具現化されたシステムの基本的な構成」踏んでるからまえたシステムの基本的な構成」上の意思決定であ で、それらの関係や環境、設計やその現場ですぐ使える原則に具現化されたシステムの基本的な構成」メソドロジーを左右する原則に具現化されたシステムの基本的な構成」これでもかと い品質特性や他の性うくらい品質特性や他の性収まって録しメンテしていくか。安心と信頼のと信頼の関係や環境、設計やそのPragProgの関係や環境、設計やそのIt!シリー ズを制限する最新しいシステム作る重要な設計上の意思決定であであり、それらの関係や環境、設計やそのRelease It!に具現化されたシステムの基本的な構成」迫る名作。る原則に具現化されたシステムの基本的な構成」名作る重要な設計上の意思決定であ。
Download now