2016年1月26日デジタルとアナログ。2016年1月12日2016年あけましておめでとうございます。康廣コメントするギルドワークスさんとパートナーとして一緒にお仕事させていただいています、木目沢(@pilgrim_reds)と申します。技術書を読むという習慣はみなさん持っていると思います。技術書を消化しようと思った時、みなさんはどのようにされているでしょうか?写経をしたり、議論をしたり色々な方法があるかと思います。今回はもう一つの選択肢として、「少し論理的に読んでみる」という方法を紹介したいと思います。根拠はなにか?について考えながら読むだけです。主題(何について)巨大なシステムのドメインについて。問題(何が問われ)巨大なシステムは複雑なので、ビジネス資産がどこだかわからない。ドメインの全体像が見えづらい。設計が理解しにくいときに起きる問題と同じことがおきる。主張(どう答えるのか)モデルの重要なコアを洗練する。設計はすべての部分が等しく改良されるわけではないから、その中でもコアを洗練することによって、最も価値のある特化した概念を浮き彫りにする。考えることで要約もできて、理解も進みやすくなり、議論の元にすることもできるのではと思います。ソフトウェアの設計というのが、ビジネスモデルの要約だと考えるならばこのような練習が設計のスキルアップに役に立つのではないかと、個人的に思っています。この本の例題を引用してみます。ジョロウグモはタコではない。ジョロウグモは8本足ではない。何か違うのがすぐわかりますよね。これはどうでしょうか?思考は閃きを必要とする。頭のよい人は閃きを得る力に恵まれている。頭のよい人は思考力もある。読むと正しそうに見えませんか?どこがおかしいか、ぜひ考えてみてください。論理トレーニング」の中の例題ですが、実際のWebや新聞の記事なんかでも論理的におかしいと気づくことがあります。考えながら本を読むのは大変疲れますが、技術書のみならず、いろいろなジャンルの本やWEBの記事を読む際などにもきっと役に立つと思います。康廣コメントする心の落ち着きは、技術的作業にとって決して表面的なものではない。これこそが重要なものである。すべて、作業責任者に心の落ち着きを与えるための手段である。ここでは心の落ち着き以外に重要なものは何ひとつない。知覚するための前提条件だからである。)ギルドワークスさんとパートナーとして一緒にお仕事させていただいています、木目沢(@pilgrim_reds)と申します。<<クオリティ>>を知覚できるものは何でしょうか?Excelの設計書?トランザクションスクリプトなソースコード?これらを注意深く、完璧に仕上げたとして心に落ち着きを与えられるでしょうか?変わり続ける仕様・業務の知識・ビジネス、100%なくすことができないバグが存在する前提がある以上、ソースとドキュメントとの乖離があるのではないかという不安と、ソースコードを変更するたびに他にも影響があるのではないかという不安は消えないのではないのでしょうか?であれば、ソースコードに変更を加えることが容易になる設計手法こそが心に落ち着きを与えうる設計であると言えると思うのです。私たちは、ドメイン駆動設計にその活路を見出し取り組んでいます。それにしても、「心の落ち着き」と「<<クオリティ>>」を結びつけるということに意外であると思う一方、ソフトウェアに携わってきた経験上、妙な納得感がありました。工程でチームが分かれる・・・などなど心を乱す要因はいろいろありそうですね。最後に、心の落ち着きを生み出すために美味しい一杯のコーヒーを飲みましょう。康廣コメントするギルドワークスさんとパートナーとして一緒にお仕事させていただいています、木目沢(@pilgrim_reds)と申します。今回は、ドメイン駆動設計における、エンティティの識別子の実装面について考えてみたいと思います。(あまり本質的な話題でなくてすみません。)エンティティの識別子、どう実装していますか?私の場合、以下の図のようにエンティティが直接LongやStringなどプリミティブの型で持ってもよいと思っていました。エンティティの識別にしか使われないのでエンティティが直接持っていた方が使いやすいと思っていたのです。ドメイン駆動設計本の例はどうでしょう・・・。ドメイン駆動設計ではプリミティブの型を使用している例も載っていますが、書籍内のサンプルを実装したDDDSampleではVoyageNumberやTrackingIdなど識別子をラップしたクラスを使ってます。実践ドメイン駆動設計本では日付時刻を含んでいるような識別子を例にあげてこのような複雑な識別子はラップしたクラスを使うべきとあります。要は識別子の複雑さや使われ方によるのかなと思います。いう曖昧な結論では記事になりませんので、識別子用のクラスを持つことで効果がでるケースを紹介したいと思います。例は、よくある求人サイトの想定で、求職者が求人に応募するようなモデルです。求人パッケージ(モジュール)。求職者パッケージ(モジュール)。求職者は求人に応募しますので、応募クラスは求人IDクラスを持っています。・・・と、クラス図だけではなんてことないのですが、パッケージ図を見るとこうなります。これが求人や求職者の識別子がプリミティブな型の場合は以下の通り依存関係を持つことはありません。実装上はこれでも問題ないのですが、ドメインの知識をソースコードに反映するということを考えると、パッケージ間の依存関係がきちんと表現できるとよりわかりやすい設計になると思います。エンティティの識別子はそのエンティティの同一性を保証してあげるだけの役割ですので、わざわざラップして使う必要がないと思いがちです。ラップして使うことで、プリミティブな型をそのまま使うことに比べてモデルをより豊かに表現することができ、ドメインの知識をより深く理解する手掛かりとすることができます。