Submit Search
Upload
ソフトウェアにおける 複雑さとは何なのか?
•
3 likes
•
1,208 views
Yoshitaka Kawashima
Follow
アーキ部 #12 「複雑さ」について語り合う会 の参考資料です
Read less
Read more
Software
Report
Share
Report
Share
1 of 23
Download now
Download to read offline
Recommended
Tackling Complexity
Tackling Complexity
Yoshitaka Kawashima
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
Koichiro Matsuoka
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
Yoshitaka Kawashima
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
Recommended
Tackling Complexity
Tackling Complexity
Yoshitaka Kawashima
イミュータブルデータモデルの極意
イミュータブルデータモデルの極意
Yoshitaka Kawashima
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
Koichiro Matsuoka
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
Takuto Wada
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
Yoshitaka Kawashima
ドメイン駆動設計に15年取り組んでわかったこと
ドメイン駆動設計に15年取り組んでわかったこと
増田 亨
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
Yoshitaka Kawashima
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
増田 亨
3週連続DDDその1 ドメイン駆動設計の基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する
増田 亨
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
増田 亨
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Takuto Wada
ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?
Yoshitaka Kawashima
ソフトウェア開発における『知の高速道路』
ソフトウェア開発における『知の高速道路』
Yoshitaka Kawashima
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
Daisuke Yamazaki
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
増田 亨
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
Yoshiki Hayama
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
増田 亨
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
Koichiro Matsuoka
ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣
Yoshitaka Kawashima
DDD sample code explained in Java
DDD sample code explained in Java
増田 亨
Are Design Patterns Dead?
Are Design Patterns Dead?
Yoshitaka Kawashima
本番障害に至る病
本番障害に至る病
Yoshitaka Kawashima
More Related Content
What's hot
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
Yoshitaka Kawashima
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
Yoshitaka Kawashima
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
増田 亨
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
増田 亨
3週連続DDDその1 ドメイン駆動設計の基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する
増田 亨
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
Koichiro Matsuoka
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
増田 亨
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
Takuto Wada
ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?
Yoshitaka Kawashima
ソフトウェア開発における『知の高速道路』
ソフトウェア開発における『知の高速道路』
Yoshitaka Kawashima
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
Daisuke Yamazaki
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
増田 亨
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
Yoshiki Hayama
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
増田 亨
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
Koichiro Matsuoka
ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣
Yoshitaka Kawashima
DDD sample code explained in Java
DDD sample code explained in Java
増田 亨
What's hot
(20)
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
イミュータブルデータモデル(入門編)
イミュータブルデータモデル(入門編)
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
マイクロサービス 4つの分割アプローチ
マイクロサービス 4つの分割アプローチ
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
3週連続DDDその1 ドメイン駆動設計の基本を理解する
3週連続DDDその1 ドメイン駆動設計の基本を理解する
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
DDD x CQRS 更新系と参照系で異なるORMを併用して上手くいった話
ドメイン駆動設計のための Spring の上手な使い方
ドメイン駆動設計のための Spring の上手な使い方
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
組織にテストを書く文化を根付かせる戦略と戦術
組織にテストを書く文化を根付かせる戦略と戦術
ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?
ソフトウェア開発における『知の高速道路』
ソフトウェア開発における『知の高速道路』
WayOfNoTrouble.pptx
WayOfNoTrouble.pptx
正しいものを正しく作る塾-設計コース
正しいものを正しく作る塾-設計コース
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣
DDD sample code explained in Java
DDD sample code explained in Java
More from Yoshitaka Kawashima
Are Design Patterns Dead?
Are Design Patterns Dead?
Yoshitaka Kawashima
本番障害に至る病
本番障害に至る病
Yoshitaka Kawashima
システムダウンのひみつ
システムダウンのひみつ
Yoshitaka Kawashima
Mavenの真実とウソ
Mavenの真実とウソ
Yoshitaka Kawashima
アンチフラジャイルの世界
アンチフラジャイルの世界
Yoshitaka Kawashima
Atomic Architecture
Atomic Architecture
Yoshitaka Kawashima
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
ウォーターフォールとアジャイルのフェアな比較
ウォーターフォールとアジャイルのフェアな比較
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
たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力
Yoshitaka Kawashima
SIerにとっての越境 @ DevLOVE 199
SIerにとっての越境 @ DevLOVE 199
Yoshitaka Kawashima
なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?
Yoshitaka Kawashima
Antifragile Clojure
Antifragile Clojure
Yoshitaka Kawashima
Boilerplate vs Magic
Boilerplate vs Magic
Yoshitaka Kawashima
既婚プログラマの時間捻出術
既婚プログラマの時間捻出術
Yoshitaka Kawashima
Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか
Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか
Yoshitaka Kawashima
マイクロフレームワークEnkan(とKotowari)ではじめるREPL駆動開発
マイクロフレームワークEnkan(とKotowari)ではじめるREPL駆動開発
Yoshitaka Kawashima
週刊Webサイトのアーキテクチャ
週刊Webサイトのアーキテクチャ
Yoshitaka Kawashima
キメるClojure
キメるClojure
Yoshitaka Kawashima
More from Yoshitaka Kawashima
(20)
Are Design Patterns Dead?
Are Design Patterns Dead?
本番障害に至る病
本番障害に至る病
システムダウンのひみつ
システムダウンのひみつ
Mavenの真実とウソ
Mavenの真実とウソ
アンチフラジャイルの世界
アンチフラジャイルの世界
Atomic Architecture
Atomic Architecture
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
ウォーターフォールとアジャイルのフェアな比較
ウォーターフォールとアジャイルのフェアな比較
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
ソフトウェアにおける 複雑さとは何なのか?
1.
ソフトウェアにおける 複雑さとは何なのか? kawasima
2.
「複雑さ」を定義する
3.
『A Philosophy of
Software Design』John K. Ousterhout ● 「複雑さ」は理解や修正を難しくするソフトウェアの構造に関連したもの ○ (定義とし書かれているのはこれくらい ) ● 複雑さだと… ○ 単純な変更でもいろんな場所のコードを修正が入る ○ 認知負荷が高い ○ 分からないことが分からない ● 複雑さの原因は… ○ 依存性 ○ 不明瞭さ
4.
『Domain Driven Design』Eric
Evans ● ビジネスルール間に矛盾が発生すると複雑 ● 同じ言葉に違う意味を持たせていると複雑 ● Value Objectで良いものにIDを持たせるのは複雑 一貫性がないと複雑 → ユビキタス言語?
5.
あいまいでよく分からない…
6.
複雑さの言い換え ● 使いにくい ● 理解が難しい ●
メンテしにくい ● 長ったらしい ● 覚えきれない ● 実行が難しい ● 管理できない ● 色々混ざっている ● たくさんの要素がある ● 一貫性がない ● 込み入ってる ● ゴテゴテしている ● 不透明 John Cutlerさんのツイートの裏返し
7.
Simple Made Easy https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md
8.
Rich Hickey定義のComplexity ● 複数の役割 ●
複数のタスク ● 複数の概念 色々混ざっている 一貫性がない
9.
もう1つの複雑さ マイクロサービスの各サービスは Simpleでも…
10.
要素が多くそれらの関係性把握が難しい 込み入っている たくさんの要素がある
11.
2種類の複雑さ ● 単一のコンポーネントに内包される複雑さ ○ 1つのエンティティ、1つのクラス、1つのfunctionに複数の責務・概念が混ざっている。単 一責任原則(SRP)に違反した状態 ○
Simpleの対義語としてのComplexの意 ● コンポーネント数が多いことによる複雑さ ○ エンティティやクラス、functionの数が多く、それぞれの役割や関係性を理解するのが厄 介。 ○ ややこしい意としてのComplicated
12.
2種類の複雑さは可換性がある つまり、巨大なエンティティや巨大なクラスを、 1つ の責務・概念に分解しても、複雑さの総量が変わる わけではない。
13.
『データモデリング入門』渡辺幸三 何をもって 「ひとつの情報のまとまり」とみなすかを明確にしたうえで、それぞれのテーブルにひとつの情報 のまとまりだけを置くように配慮する。このことによって、取り分け手順の複雑さが「テーブルの数の増加」と いう複雑さに移行する。その結果、指示を用意したり改善したりするための手間が減る。
14.
ただし2つの複雑さは対称ではない ❶の注文には、どういう概念が含まれるかパッとは分からない。
15.
ここまでの整理 込み入っている たくさんの要素がある 色々混ざっている 一貫性がない 理解がしにくい メンテがしにくい 長ったらしい 覚えきれない 単一のコンポーネントに 内包される複雑さ コンポーネント数が多いこ とによる複雑さ これら「複雑さ」から 導かれる効果
16.
生来的複雑さを選択する
17.
ここまでは、ソフトウェアが表現するビジネスの持つ 生来的複雑さが、変わらないことを前提としての 話であった。 生来的複雑さは、ビジネス要求によって変わるが、モデルの柔軟性次第でも変わる。
18.
『Analysis Patterns』Martin Fowler ●
システムに柔軟性を持たせすぎると、システムが複雑になりすぎてしまう。 ● エンジニアリングは人工物の構築 , 維持にかかるコストと、それが提供する機能とのトレードオ フを必要とする。
19.
『Clean Code』Uncle Bob ●
道具は道具箱の中に整理され、それぞれが明確に定義されラベル付けされた部品を含む多く の小さな引き出しが必要なのか?それとも、何でも放り込んでおけるような引き出しがいくつか 欲しいのか? ● 複雑さを整理するために、適切なサイズの前者が必要
20.
柔軟性と複雑さ(単純さ)のトレードオフ 例えば、「ピザ」のモデルを考える Cheese Pizza { price:
MonetaryAmount; cheese: Weight; } Pizza { price: MonetaryAmount; dough: Dough; topings: Topping[]; } Product { price: MonetaryAmount; ingredents: Ingredient[]; } 柔軟性 複雑さ (2種類の複雑さの総量 ) (潜在的に)表現可能なモデルの範囲 A) ピザの種類ごとに型を用意する B) ピザで1つの型を用意する C) ピザ以外の商品も表現できるモデル
21.
Case1 単純だが柔軟性にかける 仕様の変更時に、プログラムの修正が発生する。 連れてテーブルの変更も。 → が、このコストは年々小さくなるだろう おそらく、この設計自体が抽象的思考に至りにくいこと が、ビジネス側にも影響を与え、水平思考に繋がらない ことが最大の問題になると思う。 Cheese
Pizza { price: MonetaryAmount; cheese: Weight; }
22.
Case2 柔軟だが決まっていないことが多すぎる Ingredentsの組み合わせには、多くの制約が存在する ことが考えられるが、その制約の設計やテスト容易性を 確保することが困難。 設計時点で、モデルにその自由度が必要なのか? 過剰 な柔軟性であると、Martin
FowlerやUncle Bobの言う 通り、現時点では不必要な複雑さを導入してしまってい ることになる。 Product { price: MonetaryAmount; ingredents: Ingredient[]; }
23.
複雑さのハンドリングガイド ● 複雑さには2種類ある ○ 単一のコンポーネントに内包される複雑さ ○
コンポーネント数が多いことによる複雑 ● 単一のコンポーネントに内包される複雑さは、分解してみないと正体が見えない (すなわち実装どうするかによらず、まず正体を明らかにすることが必要 ) ● 2種類の複雑さの総量は、通常業務の複雑さによって決まるが、モデルにどこまでの柔軟性を 持たせるかによっても変わってくる。 (適度な柔軟性と複雑さを選択しよう )
Download now