omuomugin
ベストな「How」は「Why」でしか規定できない — Mercari Bold Challenge "Why Microservices?" by @deeeet
see also ベストな「How」は「Why」でしか規定できない メルカリがマイクロサービスに移行した理由と、その軌跡
よい設計は悪い設計よりも変更しやすい 我々が知る限り、この世のあらゆる設計原則は ETC (Easier to Change) 原則を特殊化したものとなっています — 達人プログラマ第二版 Tips14
ソフトウェアは「変化し続ける要求」と「戦略的ではない依存の追加や変更」によって腐っていく — Design Principles and Design Patterns, 2000, Robert C. Martin
ソフトウェアの複雑性は、「依存」と「曖昧さ」によって引き起こされる — Philosophy of Software Design
理想的な構造的な設計は、結合度を低くし、凝集性を高めることである — Comparing Techiniques by Means of Encapsulation and Connersence, 1992, Meilir Page-Jones
// Int -> String に変えた場合には ソフトウェア要素 B も変更する必要がある例 var a: Int // ソフトウェア要素 A a = 7 // ソフトウェア要素 B
疎結合かつ凝集性を高く = 境界外は「弱い」コナーセンスに境界内は「強い」コナーセンスに
— Code Complete 上 第７章 高品質なルーチン
ルーチンが処理を1つだけ実行する場合である。ここでの評価は、それらのルーチンがその名前が示唆するとおりの処理を行うと前提してのものである。他にも何かの処理を行うとしたら、凝集性は弱まり、名前も適切とは言えなくなる。 — Code Complete 上 第７章 高品質なルーチン
Software that fits in your head — Dan North (creator of BDD)
複雑な問題を完全に詰め込めるほど大きな脳を持った人はいない by Edsger Dijkstra — Code Complete 上 第７章 高品質なルーチン
// ① 引数を1つずつ渡す fun doSomething(a: Int, b: Int, c: Int, d: Int) // ② 引数に必要なものを1つのオブジェクトに詰めて渡す fun doSomething(obj: SomeObj)
これらの意見はどちらも短絡的で、ルーチンのインターフェイスが表す抽象概念とは何かという最も重要なポイントを見逃している。 ルーチンは３つの要素が渡されることを期待していて、それらがたまたま同じオブジェクトによって提供されることが抽象化であるというなら、3つのデータ要素を個別に渡すべきだろう。 しかし、常に特定のオブジェクトが存在し、ルーチンがそのオブジェクトを使って何かをすることが抽象化であるというなら、3つのデータ要素を公開した時点で、抽象化を崩壊させることになる。 — Code Complete 上 第７章 高品質なルーチン
パターンがより最悪の自体を招いたケースをある。 人々が本を読んで紹介されているパターンにワクワクしてまるで適用すればするほど良いソフトウェアになる魔法のように感じてしまった。 本来であれば、それらのパターンがどこで使用されるべきか、それらを使用する正しい方法は何か、そしてそれらをどのように適応させるかを理解する必要があるにも関わらず。 — Software Engineering Radio EP 215: Gang of Four - 20 Years Later
あるプラクティスがなぜワークするのかを理解することなく、耳かきをしながらプロジェクトが無事に成功することを願っているだけである。 カーゴカルト な ソフトウェアエンジニアは、「我々はいつもこのやりかたでやってきた。」、「我々の会社の標準はこの方法であり。」と言って意味のないようなプラクティスを正当化する。 — Cargo Cult Software Engineering, March/April 2000 IEEE, Steve McConnell
彼らは中身を伴わない、形を真似ただけだったのです。人類学者はこれを「カーゴカルト」と呼んでいます。 我々はしばしば、この島の島民と同じ行動をとろうとします。 このカーゴカルトの罠に誘い込まれ、はまってしまうのは簡単です。目に映りやすい特報に投資し、それを作成することで、何らかの魔法のような結果を呼び込めると期待してしまうのです。 — 達人プログラマ 第2版 Tips 87
戦略的、そして戦術的に設計したドメインモデルは、特定のアーキテクチャに依存するのではなくアーキテクチャ的に中立であるべきだ。 — 実践ドメイン駆動設計
ユビキタス言語が注目するのは、その業務自体が、どのような考えのもとでどのように動くのかということだ — 実践ドメイン駆動開発
// どうでもいいからさっとコード書こうぜの人 //... patient.setShotType(ShotTypes.TYPE_FLU); patient.setDose(dose); patient.setNurse(nurse); //...
// 「インフルエンザの注射を患者に打つ」まで分析できた人 //... patient.giveFluShot(); //...
// 「ナースが患者に、インフルエンザワクチンを適量投与する」まで分析できた人 //... Vaccine vaccine = vaccines.standardAdultFluDose(); nurse.administerFluVaccine(patient, vaccine); //...
名前を言えるようになったとたんに、いたる所でそれを見るようになりました – Robin Williams ノンデザイナーズ・デザインブック
若かりしころすべての業務で統一されたモデルを作ることとアドバイスされた。しかし DDD でわかったことは統一されたモデルは大規模なシステムにおいて不可能か費用対効果に見合わないことがわかった。 — ドメイン駆動設計
境界を越えてモデルを扱うと様々な意味を含んでしまうことになる 結果としてモデルが複雑になり、腐っていってしまう
※ 詳細には立ち入らないです！
※ DTO = Data Transfer Object ※ DPO = Domain Payload Object
※ RPC = Remote Procedure Call
※SOLID原則と共に紹介されるパッケージにおける原則
※SOLID原則と共に紹介されるパッケージ間の関係における原則