フォローしましたこの記事は、岩手県立大学アドベントカレンダー12日目の記事です。ついてとりとめの無い引用とコメントをします。ソースコードの依存性は、内側(上位レベルの方針)だけに向かっていなければならない円の内側は、外に依存してはいけないということだ。エンティティとは、ビジネスデータとビジネスロジックを扱うクラスとして考えよう。これはどのようなアプリケーションからも普遍的に利用出来る。ユースケースは、アプリケーション固有のビジネスルールを取り扱う。インタフェースアダプターは、その外にある存在を扱うのに便利なフォーマットに変換するアダプタである。フレームワークとドライバは、DBやウェブフレームワークである。このレイヤはコードを書くことはあまりない。この円をみたときには、なにを言っているのかさっぱりであった。実際にコードとしてみるとその利便性(と歯がゆさの両面)がわかる。コード量が多くなる傾向にある。これはソフトウェアあるいはビジネスの寿命を加味しながら適切に活用する必要がある。は長い息のビジネスには大変に有用かと思う。一方で、ベンチャーのようにピボットと呼ばれることがあり得る世界にはオーバーエンジニアリングであると考える。熱心な信者が布教しているようで、この辺の案配を考慮せよと書いている記事は少ない。層を増やす、というのが現実的な戦略ではないだろうか。==非常に頭のいい人たちが、抽象化が必要になることを予測してはいけないと提唱してきた。これがYAGNIの哲学である。このメッセージには、オーバーエンジニアリングのほうがアンダーエンジニアリングよりも悪質であるという知見が含まれている。アーキテクチャの境界が必要なところになかったとしたら、境界を追加するコストやリスクは非常に高いものとなるだろう。「YAGNI」という言葉は、エクストリームプログラミングから提唱された言葉である。必要になるまで機能を追加するな、あるいは早すぎる抽象化は悪、といったことが言われる。著者はここに疑問を呈している。ソフトウェアアーキテクトは未来に目を向けろという。完全に実装しろとはいわないが、実装すべきか無視するべきか常に見張り判断していけという。近年でいう、XP、アジャイル、リーンといった手法は、未来は予測できないという前提にたつ。僕もその思想には一定の理解があるが、やはり人である以上、未来をある程度予測する必要があると考える。変化に機敏にというと言葉はいいが、場当たり対応は基本的には割けるべきことであり、リスクコントロールの範疇である。将棋やチェスの13手先は読めずとも、7手先くらいは読めたほうがいい。それには経験と知識が必要である。これこそ著者の言うことなのではないだろうか。==「訳者あとがき」はとてもおもしろい。僕がスッキリしないことをしっかりと書いている。異論のある方もいらっしゃるだろう。私もすっきりしていない。Webアプリケーションを開発するときに、フレームワークを選定しないことがあるだろうか?訳者も納得していない様子だ。著者はこれまでの経験を引き合いに出しながら、圧倒的な説得力で力強く迫ってくる。おまえのアーキテクチャは、見ただけでわかるようになっているのか?ドメインについて正しく叫んでいるのか?そのように問いかけてくる。この本は、どうも疑問と思うところを圧倒的な言い切り方でねじ伏せてくる。それは、アンクルボブの経験と信頼が成せる技なのかもしれない。フレームワークから着手しないことが本当に正しいことなのか、私にはまだよくわからない。本書で紹介されている例は、いずれも現代的なアプリの話ではない。大昔の話を何度もされても困るのだが(翻訳も大変だし)、それでも「時代を超越した普遍のルール」が存在するとして、著者はいつまでも原理・原則に忠実であろうとする。訳者の正直さがうかがえる。Architecture」については、すでに著者本人がブログや講演などで情報発信していることもあり、見よう見まねでアーキテクチャの「同心円」を実装している例が数多く見られる。著者のように原理・原則に忠実であるためにも、まずは本書に目を通してもらいたい。著者と対話しながら、自らのアーキテクチャをクリーンに仕手もらえれば幸いだ。多くのWeb記事はあまりにも稚拙だったと思う。このような背景を取り扱わず、単にあるプログラミング言語で同心円を実装しているに過ぎない。答えを求めすぎである。ある意味、アーキテクチャはアートであるから、すぐにそこにたどり着いてはいけない面もあるのではないだろうか。デザイン(設計)は、課題の解決案を示し、アートは、課題を問いかけるという。その面に立つと、アンクルボブが示した課題を単に受け入れるだけでなく、議論し、次に進めていく必要があるだろう。==ここまで、全3回の感想を示した。訳者ではないが、正直に言って僕も納得のいかない部分、あるいは理解しがたい部分がある。経験をまとめたベストプラクティスとしては秀逸なアーキテクチャなのだと思う。理解できない部分はエンジニア同士でぜひ議論をしていきたいです。興味のある方は、盛岡でランチでもしながらお会いしましょう。@isseium技術系記事は書くのに時間がかかるので、明日以降そろそろポエムっぽい方向にいきたいと思っている次第です。ダウンロードこの記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。盛岡の頂点を目指して。Haraかんたんなプログラムを書くために気をつけていること54hirothings久々に興奮する本に出会った。クリエイターへのお問合せnoteカイゼン目安箱クリエイターの。