システムの複雑さはどこから来るのか – Out of the tar pitを読む - Uzabase for Engineers

Uzabase Saas Product Divisionフェローの矢野です。 この記事は、Rich Hickey（プログラミング言語Clojure作者）のプレゼンテーションSimple Made Easyへと繋がっていく、Ben MoseleyとPeter Marksによる「Out of the tar pit」というシステム設計について論じた論文の内容について説明したもので、ユーザベースのSaas Productでのテック発表の一つとしてプレゼンしたものを、ブログとして再度まとめたものです。プレゼン自体は25分くらいでしたので、おそらくこの記事の方がプレゼンよりも詳しいと思います。 ソフトウェア危機 プログラミングとシステムデザインの方法論は、『構造化プログラミング』の時代から徐々に発達してきた、歴史の流れがあって、今見えている最高に人気のある手法も、そのような歴史の流れの末端です。直

[turanukimaru]

DDDは"対象領域をドメインと呼ぶ"と良く誤解されてるが、"必須の物だけ境界に含め領域を作る"ほうが本質。自然に国境が無いように境界もない。必ず意図を持って作る。呼び方だけ"ドメイン"にして満足してる人多すぎ。

[circled]

自分だけが使うプログラムを作るのは簡単なんだけど、それを多くの人に使って貰おうとする時には「電子レンジで猫を乾かそうとしてはいけません」みたいな注意書きを考える必要が発生するのが地獄だと思う。

[nunulk]

"このように、状態からロジックを抽出していくと、なんとなく状態として扱ってしまっていたものが、実は状態ではなく、ロジックだということがわかってきます。年齢も、現在地も、状態ではなくロジックなのです。"

[non_117]

何をやっても減らない条件分岐が必須な複雑さだよ / ソフトウェアが複雑なのではなく社会が複雑なんですよ / この手の設計論は初学者に伝わらないのだがどうしたもんかな

[bayashi_net]

システムの難しさは、複雑さより暗黙なものだなあ。近年のプログラム言語の進化は暗黙なものを簡潔に明示的に書く方向だと思ってる。

[dexia2]

最初は抽象的な話で難しいなと思いましたが、Clojureの言語仕様やライブラリの経験などを思い出すと、理解できました。Clojureは原理に忠実でわかりやすいですね。

[yojik]

“この論文は2006年のものですから、Clean Architectureとかもまだありません” 本としてのクリーンアーキテクチャ自体はボブが昔から言ってることをまとめなおしただけだから、微妙に引っかかる表現かもしれない

[rti7743]

この場合は除くの例外的処理からくるものだと思うよ。赤は停止、青は進めだけならいいけど、ただし矢印が出ている側に曲がる場合は除くって条件がつくだけでも複雑さは増すわけだし。そういうのがたくさんあるわけで

[quanon]

「必須な複雑さ」と「付随的な複雑さ」を区別する。なるほど。プログラミング言語がパワフルでなんでもできるがゆえに複雑は生まれるので、領域ごとに専用の DSL を用意し、やれることを制限するってのもおもしろい。

[dltlt]

ユーザ側が、多数の条件分岐で繋がったステイタス群を「必須」指定してきたらどうするのだろう。

[daaaaaai]

複雑さの原因4つのうちの状態にフォーカスして複雑さに対峙しようとするのおもしろい

[masa8aurum]

必須の(Essential)複雑さ、付随的な(Accidental)複雑さ

[igrep]

本当に必要なのは「ユーザーの入力」だけでそこから要件上計算しないといけないものが「必須のロジック」で、それで求めた結果を保存したり表示したりするのは付随的な複雑さ。センサーの入力もユーザーの入力の内？

[yuki_2021]

設計とかクリーンアーキテクチャについて。

[motchang]

"Simplicity is HARD"

[Nnwww]

いかに外部へ必須でないステートとロジックを払い出していくかという設計手法(手順)の一例。何気に昨今のイケイケシステムが生じた理由の一般化された説明として便利そうで興味深い。

[rgfx]

いい話

[efcl]

複雑さを - 必須の(Essential)複雑さ - 付随的な(Accidental)複雑さ にわけて、computedとして表現できるステートは必須ではないので、切り離す。 キャッシュ/メモ化などで表現することで複雑さを分離する

[toenobu]

“Fなどの分岐が、ユーザーの直接の要求であるケースもあるのでは？ ゴールド会員はポイント２倍とか。 でも、世の”

[h_taiji]

保存

[sawat]

現在地を「状態」ではなく「ロジックとキャッシュ」にすることで本当に複雑さが減るのだろうか？キャッシュにはキャッシュの複雑性がある（いつクリアするのとか）。複雑さが見えにくくなっただけではないだろうか？

[dot]

システムは業務の写像だから業務が複雑ならなるべくしてシステムは複雑化する。業務の枝葉をできるだけ払ってシンプルな業務を保つのがシステムが複雑化しないための秘訣だと思ってる。

[NOV1975]

汎用プログラミングは敵だみたいな話？／要件が複雑なシステムをシンプルに作ろうとすると外部のどこかが複雑になる、というだけな気がしているけど。

[ko-ya-ma]

関数型言語への招待…とも読める

[kaiton]

例外が増える、前提が変わるかな？

[kagehiens]

一理あるけど、それがメインじゃないよね……、業務系の場合だけど。

[Magicant]

いかにも関数型畑の人が考へさうな話 / 複雑さの定義を狭めることで複雑さは少なくなるのだといふ主張といふか欺瞞

[iwtn]

毎回無限の計算はできないから、むしろデータというか状態を持ち続けたほうが良い？FRPは面白そう。

[sugawara1991]

計算で導出できるものを状態として扱わないのはレイテンシとかでむしろ性能上有利になる可能性すら。リスト構造を直ポインタでなくインデックスで実装する件とか。状態不整合バグも避けるし

[otihateten3510]

仕様

[buhoho]

"「複雑なシステムから複雑さを取り除く」のと「シンプルさを重視してデザインされた遅いシステムのパフォーマンスを改善する」のとであれば、後者の方がきっとマシ" せやな。好きな考え方