00:03
はい、7月4日月曜日ですね。はい、地獄浅久城もありました。 まぁやっぱりいにくの雨ですね、東京は。まぁ台風も近づいてきてるそうなんで。はい、おはようございまーす。
kkeethのくわ、こと、くわはらです。では本日も朝から始めていきたいかなと思います。 えーとー
まさひろさんですね。はい、参加ありがとうございます。 今日も、えっとき、タイトルにあるときのCupidの記事。 今日が多分最後かな。読み切っていきたいかなと思います。
では、えっと、やっていきましょう。えー、今日はですね、昨日に引き続き、そのフィロソフィーの最後ですね。 第5つ目、ドメインベースの話が入ってきております。
で、あとはそれを読んだらコンクリューションで終わりかなってところですね。 はい、じゃあ早速入っていきたいと思います。
えー、我々はあるニーズを満たすためにソフトウェアを書きますと。 で、それは特定の状況に対応するかもしれませんし、まぁ一般的で広範囲に及ぶものかもしれません。
どのような目的であれ、コードはあなたが書いたものとそれが実行することの間の認知的距離を最小にするために、問題領域の言語でそれが何をしているかを伝える必要があります。
これは正しい言葉を使う以上のことです。 はい、ここで言う正しいっていう概念と、あのー、その、認知っていうところですね。
ここが結構ポイントなんだろうなって気はしましたね。 はい。
まあ英語的にも確かにusing the right partsって言ってますから、まあ確かに正しいって訳すのが普通だと思うんだけど。
はい、これはちょっとこの後出てくるかもしれないので、一旦読み進めてみましょう。 はい。
大地さんですね。おはようございます。ご参加ありがとうございます。 はい、タイトルある記事を、今日多分最後までですかね、読み切りたいと思います。
はい、じゃあドメインベースのlanguageですね。ドメインベース言語っていうところからいきますね。
はい、プログラミング言語とそのライブラリには、ハッシュマップとか、まあ、えーと、
リンクリエストか、はい、と、ツリーセット、データベース接続など、コンピューターサイエンス的な構成要素っていうのがたくさんあります。
基本的な型は、まあ整数や文字とか、ブリアンチなどからなりますね。と、いわゆるプリミティブ型ってやつですね。
はい、で、誰かの性、性っていうのは名字の方のことかな、はい、を文字列30として、例えば、まあ宣言することができて、それがそのまま保存されるかもしれませんが、
サーネーム型を定義することで、まあより意図が明らかになることでしょうと、はい、ということで言ってますね。
サーネームって僕は初めて聞いたんですけど、そんな型があるんですね。はい。
で、性に関する操作とかプロパティ、もしくは制約を持つこともまあ確かにできますよと。
はい、金融ソフトのプログラマーとかは、まあ通貨と金額を組み合わせた複合型であるマニー型を定義したりとかするそうですね。
えー、僕はちょっとあんまり金融のお仕事をしたことがないんで、そうなんやって感じですね。
まあECだと似たようなこと確かにやったりしますけど、まあ型というか、あれですね、データベースのカラム的に定義することはいっぱいありますけど、
まあここにおけるその型、まあいわゆるタイプですけど、どこにそのタイプとして定義してるのかちょっとわかんないですね、これは。
03:06
まあまあね、一旦削り抜きましょう。
えーと、まあ型や演算の名前をうまくつけるっていうことは、単にバグを発見したり防止したりするだけでなく、
コード上の回答空間というのを明確にし、ナビゲートしやすくするためでもありますと。
私はこれをプログラマーが知っておくべき97のことに、ドメインの言語でコードを書くとして寄稿しましたと。
あー、なるほどですね、なんか既視感のあるなんかワードだなって思ったらそうか。
だいぶ前に読んだ、プログラマーが知っておくべき、知るべき97のことか、日本語訳の方がですね、の書籍に書いてあるやつですね。
はい、この書籍本当におすすめなんで、ちょっといきなり余談に入っちゃいますけど、ぜひぜひみなさんも読んでいただければと思います。
で、現在は本の書籍買わなくてもですね、オンライン上でプログラマーが知るべき97のことは読めるので、
はい、もし興味ある方はウェブでガッと調べてみたら、しかも日本語で確か読めた気がしますので、
はい、検索してみていただければなと思います。
まあ一個一個そんなに長くないものを97人の人が書いているので、そんな感じで読んでいただければいいなと思います。
で、さらにもう一個余談を打ち込むと、プログラマーの読めが知るべき97のことっていうパロディー記事もあって、
あのもう今はあんま当てはまらないことが多いですね。
ただ昔の本当に大変だった頃のプログラマーの方っていうのは、そういうことがガチであったんだろうなっていう参考程度というか、
もう本当にただの遊びとしての読み物で面白いものがあるので、読めが知るべき97のことですね。
読んでいただければと思います。
ただ僕新卒の頃でもあれ、意外と5、60個ぐらい当てはまったので、しゃれ気になってないなっていう感じですね。
まあ大変な時期があったっていうぐらいの、一つのバロメーターとして見てもらうと、まあ割と面白いと思いますね。
はい、余談でした。
では私は戻りますね。
ドメイン駆動型のコードの成功の一つの基準っていうのは、人々がコードとドメインのどちらを議論しているのか、傍観者には分からないということですと。
例えばですね、とある電子取引システムで金融アナリストが、2人のプログラマーと複雑な取引価格設定のロジックについても議論していたとしましょう。
その時に私は、はい、私はこれを経験した、筆者の方は実際これを経験したらしいですね。
私は彼らが価格設定のルールについて議論していると思ったんですけど、彼らは画面いっぱいのコードを指差して、アナリストはプログラマーに価格設定のアルゴリズムについて話をしていたと。
問題領域とそのソリューションコードの間にある唯一の二日的な距離というのは、いわゆる口文と苦闘点だけだったのです。
これは実質に、事前に今何の話をしていますかというのをちゃんと一橋を叩きながら話せば全然いい話な気がしますけど、まあでもよくある話ですねこれは。
同じような話題というか、金額とか価格の話をしているんですけど、ロジックの話をしているのか、それよりビジネスロジックの話をしているのか、アルゴリズムの話をしているのかは全然別の話ですので、実はね。
最終的にはお互いが歩み寄る必要はあるんですけど。
06:00
はい、なるほどということですね。
はい、なので必要なのは実はその口文の苦闘点だけだったというところで、なかなか面白い話ですね。
はい、でも要はドメインベースってところに確かに立脚したお話だなと思いました。
はい。
では続いて、さっきはドメインベースとランゲージだったので、今度はドメインベースとストラクチャーですね。構造の話だと思いますね。
はい、ではいきます。ドメインベースの言語を使用することはとても重要ではありますけど、コードをどのように構造化することかも土曜に重要であるという場合がありますよと。
多くのフレームワークでは、ディレクトリーレイアウトとかスタブファイルとかを含むいわゆるスケルトンプロジェクトというのが提供されていて、すぐに始められるように設計はされていますと。
これはあなたが解決しようとしている問題とは全く関係のない、いわゆる先見的な構造をコードに押し付けるものでありますと。
はあ、なるほどね。僕らはやっぱりボイラープレートとか、最初から用意されたスケルトンプロジェクトをむしろ欲しいと思う側なので、この視点というかこの意見は面白いですね。
先に構造をコードに押し付けるというのはちょっと考えたことがなかったですね。
人が考えるというか、そういう構造的なものってやっぱりプロジェクトを進んでいたり、開発している途中で逐一リファクタリングしたりとか見直しをしたりするような、いわゆるランニングしながら作っていくものだと思ったので。
まあでもこの人はスタートからすでに押し付けているという観点で物事を見ているんですね。
むしろディレクトリ名とか子供のフォルダーとか兄弟フォルダーの関係であったりとか、関連ファイルのグループ化とか命名など、コードのレイアウトというのは問題領域をできるだけ忠実に反映する必要があります。
単なるディレクトリ構成だけじゃないし、フォルダーごとの関係性もそうですし、名前もそうですしということですね。グルーピングもそうです。
アプリケーションフレームワークのRuby on Railsとかは、2000年代の初頭にこのアプローチをツールに組み込んで普及をさせましたと。
Railsが広く採用されたことで、その後の多くのフレームワークがこのアイディアを模倣するようになりましたということですね。
言われてみればそうかもしれないですね。僕昔、PHP書いたところ。
何だっけかな。あ、忘れた。あれですね。コードイグナイターとか。
あとFuelも若干あってましたしね。Sナは書いてないけど読んでたりはしましたけどね。
でも確かにその辺のフレームワークでこんなような概念が確かにあったかというと意外となかった気がしますね。
なるほどね。まあでもそもそも側の話はしないと思いますし。
一旦置いておいて。
Ruby on Railsがそれのようなアイディアを導入して普及したことによっていろんなフレームワークがそれに習ってきたということですね。
今回のこの本記事の主題であるCUPIDというのは、言語やフレームワークに依存はしませんが、
Railsはドメインベースとフレームワークベースの構造の違いを理解する上でとても有用なケーススタディになりますよと言ってますね。
09:02
例えば以下は、作成されたRailsアプリのスケルトンのディレクトリレイアウトの一部ですと。
今確かにディレクトリのマップが下に表示されてるんですけど、ちょっと後ほど読みますね。
見せてるのはそのディレクトリレイアウトの一部で、開発者がいわゆる最も時間を費やすディレクトリ、
アップディレクトリに焦点を当てていますと。
完全なスケルトンというのは、出品時点で60のファイルを含む約50のディレクトリに分かれていますということですね。
いわゆるアップディレクトリがあって、その下にアセッツとチャンネルとコントローラーズ、
あとヘルパーズ、JavaScript、ジョブズ、メイラーズ、あとモデルズとビューズですね。
結構僕がRailsを触ってたときは5.1だっけ?
Webpackerが導入された頃に僕若干Railsを触ってたんですけども、
その頃からやっぱり全然ディレクトリ構成変わりましたね。
新しいものを追加されているなという印象があります。
ただ、よくあるMVCと言われているモデルズビューズとコントローラーズはやっぱり外さないし、
あとヘルパーズとジョブズというのが僕は全然新しいなと思いました。
メイラーズもちゃんとディレクトリ切られたんですね。
というところで、ふうに分かれています。
デフォルトで60のファイルを含む50個のディレクトリにしっかり分割をされているということでした。
でもこれがいわゆるストラクチャーベースと言われているものなんでしょうね。
続けて読んでいきたいと思います。
また別のケーススタディーか、具体例ですね。
病院の管理アプリで患者記録のセクションがあると想像してください。
このレイアウトですね、今見せたそのディレクトリのレイアウトというのは、
少なくとも以下のものが必要であることを示唆しています。
よくやるやつですけど、3つですね。
とにかくモデルとビューと、あとビューモデルかな。
コントローラーか、モデルとビューとコントローラーがやっぱり必要ですよと言っています。
モデルはいわゆるデータベースにマッピングするもので、ビューというのはやっぱり画面に表示する側の話ですね。
コントローラーというのはビューとモデルの間を取り持つものですよということです。
それからヘルパーであったりアセットであったり、いわゆるモデルの関心ごとの、コントローラーの関心ごとのとか、
メーラー、ジョブ、チャンネル、ほげほげってありますけど、
Rubyコントローラーと一緒に使うJavaScriptコントローラーなど、
いくつかのフレームワークのコンセプトが必要になりますと。
これらの成果物っていうのは意味的に緊密に統合されているに関わらず、
それぞれ別のディレクトリに格納されていますと。
なるほどですね。
患者記録管理に対するどんな小さな変更もコードベース中に散らばったコードを含む可能性があります。
ソリッドの原則であるシングルレスポンシビリティというのは、
ビューコードとコントローラーコードは分離されるべきであるとされていますが、
レールズなどのフレームワークではこれを全く別の場所に配置することと解釈しています。
レールズの態度はそうですね。
これは認知負荷を高め、結束力を弱め、製品の変更を行う際の労力を増やしますと。
12:01
先に述べたように、このイデオロギー的な制約は、
仕事を難しくしコードベースを楽しくしてなくしてしまうようなことがありますよと言っています。
なるほどですね。
この人はソリッド原則がちょっと怪異的と言いますか、
自分の中ではフィットしていないのかということがよく分かりますね。
態度によく分かれている。
確かに分からないくはない感じはありますけどね。
いろんなものをどんどんどんどん小さく分割していったり、
システム的には分けた方がいいでしょうし、
製品の変更可能性とかを加味したらそれは分ける。
意味的にしっかり分離しておくことは悪いとは思わないですけど、
それによって労力が増えてしまう可能性もあるし、
いわゆる結束力っていうのは依存関係で意味じゃないと思いますね、これは。
本当に使い勝手としての結束力が弱まってしまうので、
コードベースを楽しくなくしてしまう可能性があるっていうのは視点としては分かるなって感じがしました。
続きますね。
どのようにコードをレイアウトするにしても、
モデルとビュートコントローラーなどの人工物はもちろん必要にはなりますが、
それらをタイプ別にグループ化するっていうことは主要な構造を形成するべきではありません。
その代わりコードベースのトップレベルでは病院管理の主なユースケースを示すべきです。
例えば、patient historyですね。
患者の履歴っていうところです。
とか、appointmentとか、staffingとか、
complianceだとか、みたいなところですね。
そんなユースケースをコードベースのトップレベルで示す方がいいんじゃないの?
っていう風に言ってますね。
これやっぱりドメインの観点に基づいたご意見だなと思いました。
コード構造上にドメインベースのアプローチを取ることで、
コードが何のためにあるかを理解しやすくなり、
あのボタンを水色にする以上の複雑なことをする必要がある場合に、
どこにでも簡単に移動できるようになります。
なるほどね。
そんなに小さなSDケースを出さなくても別にいいと思いましたけども。
ドメインベースに考えるとそういうことですね。
今のがドメインベースでストラクチャーでしたね。
最後、ドメインベースとバウンダリーズですね。
このところを行って、ドメインベースの観点は終了になるかなと思いますね。
最後です。ドメインベースのいわゆる境界ですね。
バウンダリーズ。
コードを思い通りに構成し、思い通りな名前を付けると、
モジュールの境界がドメインの境界となり、
デプロイが簡単になります。
コンポーネントを単一のアーティファクトとしてデプロイするために
必要なものはすべて揃っているので、
ドメイン境界とデプロイ境界を一致させ、
まとまったビジネスコンポーネントやサービスを
デプロイすることができるようになるのです。
製品やサービスを単一のモノレースとしてパッケージ化するか、
多数の小さなマイクロサービスとしてパッケージ化するか、
あるいはその中間であっても、このように整合させることで
可動までの道のりの複雑さを軽減し、
何かを忘れたり、異なる環境や異なるサブシステムからの
成果物を含めたりするというような可能性を
フィックスすることができます。
これは単一のフラットなトップレベルのコード構造に
15:03
制限されるものでありません。
ドメインにはサブドメインがあって、
コンポーネントにはサブコンポーネントがある場合もあります。
デプロイは変更とリスクとプロファイルに適した
流度で行うこともできます。
コードの境界をドメインの境界と一致させることで、
これらすべてのオプションの説明が容易になり、
管理も容易になりますよと言っています。
というところがドメインベースの境界という話でした。
これはもうアプリケーションの構造というよりも
その先のデプロイリリースの話に
結構重きを置いたというような観点ですね。
そういわゆる境界は確かにあって、
それをどこまでパッケージ化するかというのは
別の議論であるかもしれないですけど、
とにかく成功を取ることは大事なんだということはわかりましたね。
逆に成功をしっかり取ることで、
イレギュラーパターンであったりとか、
外部からの成果物をどんどん含めたりするみたいな、
あんまりやりたくないケースというのを
確実に減らすことはできるよということも言っていますね。
単一のフラットなトップレベルのコード構造というのは
さすがに難しいんじゃないかなと思いますね。
別に制限されるものでもないと確かにおっしゃっていますしね。
そうですね、サブドメイン、サブコンポーネントとか
その辺の話はよくある話だと思うので、
はい、また今余談でした。
以上、今の五つのフィロソフィーの最後、
ドメインベースというところの観点でした。
はい、じゃあ最後、これでその続きが、
はい、最後ですね。
コンクルーティング・ソーツというところですね。
はい、結論的な考え方というところに入って、
この本記事は終了になりますね。
いやー、長かった。
実に3日間かかるとは思わなかった。
はい、じゃあ最後にというところに行きましょう。
私は、失礼。
私はこれらの特性、括弧組み合わせ可能性と、
この五つのCUPIDのやつですね。
コンポーザビリティとユニックスフィロソフィー、
あとはプレディクタビリティと
イリオマティックで最後さっき読んだドメインベースですね。
はい、組み合わせ可能性とユニックス哲学、
いわゆるしっかり単一なものにしていきましょうというやつですね。
あと予測可能性と、
イリオマティックだから簡易オークか。
簡易オークで最後ドメインベースであること。
これらの特性っていうのを、
より多く持っているコードはそうでないコードよりも
一緒に働くのが楽しいと信じています。
私はそれぞれの特性を独立して評価していますが、
これらは相互に補強し合うものだというふうに考えています。
これはそうですね、今まで読んできた感じですごくしっくりきています。
割とかぶるというか、
立場とかプログラミング開発しているフェーズによって、
今はこの五つの観点のこっちを使うべきだなっていうのはあるんですけど、
でも実際に書いてあったり、
コンセプトは一緒だったりするのがあるので、
本当に相互に関係し合っていくものだなと思いました。
ソリッド原則みたいに五つが全部しっかり分離されたコンセプトとか、
概念じゃないなっていうところを結構読んでいて面白かったですね。
こんなふうにソースコードを見たことがなかったっていうので、
これは本当に皆さんも読んでみてほしいなと思うものではありますね。
18:03
で、ちょっと戻りましょう。
一つのことをきちんとこなすコンポーザブルで包括的なコードっていうのは、
信頼できる友人のようなものです。
寛容的なコードっていうのは、寛容っていうのは寛容句の寛容ですね。
寛容的なコードっていうのは、見たこともないのに親しみを感じます。
予測可能なコードっていうのは、
余ったサイクルを他のサプライズに集中させることもできます。
ドメインベースのコードっていうのは、
ニーズからソリューションまでの認知的距離を最初にします。
これらの特性の中心に向かってコードを移動させると、
発見した時よりもより良い状態になります。
CUPIDはあくまで頭文字を取ったものですので、
それぞれの文字にいくつかの候補がありました。
この5つを選んだのは、何らかの形で基礎になるというふうに感じたからです。
この5つから他の全ての候補の特性を導き出すことができます。
今後の記事では、候補から外れた特性についても、
CUPIDのソフトウェアを書くことで自然に得られる結果について見ていきたいと思います。
私はこのCUPIDを使った冒険を、逆に皆さんにも聞いてみたいなと思っています。
既にこれらのプロパティを使用してコードを評価したり、
マレガシーコードをクリーンアップするための戦力を策定しているチームの話を聞いています。
一方で私はそのCUPIDをより深く理解するために、
それぞれのプロパティを順番に並べて、いわゆる明確例しているような
他のものも見ていきたいなと思っています。
というので締めくられています。
という感じでした。
実にこの人は30年でしたっけ、
コードをずっと書き続けたというベテランの方なので、
途中途中に出てくる記事とか参照しているものとか、
あとはやっぱりケントベックとかマーチン・ファブランみたいな
本当に著名な方々の概念とか考え方、いろんなものを組み合わせて
この一つの考え方というところにCUPIDにたどり着いたというところですね。
なのでやっぱり参考になるし、
その通りだなって思うこともたくさんあったので、
ぜひ読んでいただければなと思います。
ただ一方で、割と最初立脚してたところがですね、
ソリッド原則っていうのがやっぱり自分にとっては
正直な使い物にならない意味では結構強い言葉を使われていたので、
そんなことはないだろうって思ったんですけど、
もともとの観点というか、
ものの見方が違うんだなっていうところはちょっと面白かったですね。
ソフトウェアっていうのは本当にただのコードですね。
プログラミングとかコードっていうものをツールであったり道具であったりとか、
あくまでシステムとの会話するためのものと捉えてなくて、
本当に仕事をする仲間ぐらいの感覚でこの人は捉えていて、
そこから物事を考えたときに、やっぱりソリッド原則はちょっと辛いというか、
自分の考え方に合わないっていうところに立脚をしていて、
CUPIDでこういうのを考えたんだなっていうのが書かれていたので、
そういう観点で見たことないですけど、
それはそれだけ、全くもって違った視点で読んでてそこが面白かったので、
はい、そんな感じ、感想ですね。
じゃあ現場でどこまで使えるかっていうのはまたまたそれまた難しい話で、
まずこの5つの原則、やっぱりちゃんと理解していかないといけないなって思いますし、
21:04
実際の現場のソースコードとか自分たちの開発のフェーズにおいて、
どの観点が当てはまるのかとかいうところを一回突合させてみて、
導入させていくのが必要なので、
割とこれまずそもそも認知負荷が高いですね、この考え方自体が。
ただ入ったらすごい上手いこと泳げるような感覚は正直にあるので、
興味はあるんですけど、
まあなかなか流行るかっていうとそうではないような気もしますね。
まあ結構好み分かれる気がしますけど。
はい、という感じでした。
一応そのプログラミングとかのいわゆるデザイン、設計の方のデザインですね、
の考え方としてCUPIDってのがありますよっていうご紹介でした。
はいじゃあちょっと短いですけど、
ちょっと今日の朝方はこちらにしようかなと思います。
残り5分で他何か記事読めるかなっていうのを一応ざっと探してはいたんですけど、
今のところ思いつかなかったのと、
まあ次に読みたい記事がまた英語なんですけど、
長いものなので、
それはまた別途で、
また明日以降読んでいこうと思います。
読もうと思っているものは、
さっき出てきたケントベックとかマーチン・ファウラーの、
なんか良さげな記事のリンクがいくつかあったので、
それのどれかをちょっとピックアップして読んでいこうかなと思いました。
じゃあ短いですけど、
今日はこちらで以上にしたいと思います。
ご参加いただいたたくさんの方ありがとうございました。
ちょっとあいにくの天気ですけど、
今日から月曜日1週間頑張っていけたらなと思います。
では終わりにします。お疲れ様です。
