トーク

GoF（Gang of Four）のデザインパターンは、我々が日々行う設計行為において基礎的な要素を占めています。ですが、一方で「デザインパターンをなんとなく知っている」状態から「デザインパターンを正しく使う」状態へ向かうには、大きな壁があると感じています。
その壁をどうよじ登れるかを考える上で、デザインパターンが何に影響を受けたのかを理解することは大きなヒントになるはずです。それは、建築家アレグザンダーの「パタン・ランゲージ」という概念です。「パタン・ランゲージは何を解決しようとしたのか」・「デザインパターンとパタン・ランゲージの差異は何か」といった点を理解することで、デザインパターンのより深い理解に繋がります。
そこから、デザインパターンにおいて「理解すればいい点」と「実践値から磨くべき点」がそれぞれどこなのかを抑える、使い方の言語化を試みます。

オブジェクト指向プログラミングの古典的な教科書として、バートランド・メイヤー氏の『オブジェクト指向入門』があります。
この書籍の『原則・コンセプト』編では、OOPを実践する上で重要な考え方である「契約による設計」について詳細に解説されています。
契約による設計は、現代のプログラミング言語においては「アサーション機能」として実装されています。
ではこのアサーション機能、いったいどのような考えの元で利用すれば、本来の用途に即した効果を発揮するのでしょうか？
簡単に導入できて非常に強力なツールであるアサーションを用いて、信頼性の高いソフトウェアを作る方法をご紹介したいと思います。

「オブジェクト指向など知ったこっちゃない」と言わんばかりに、何も設計せずただただswitch文を書き連ねて行った先の地獄を、実体験を踏まえ、面白おかしく皮肉った動画です。
(参考：クソコード動画「共通化の罠」 https://twitter.com/minodriven/status/1127539251761909760 )

動画の中で何がマズかったのか、設計やチームワーク等の観点で解説致します。
そしてこの動画を他山の石として、実際のチーム開発での活用ポイントについても説明します。

オブジェクト指向を操るとき、私たちは当然のように新しい世界を構築しています。

「鳥（オブジェクト）」が「飛ぶ（メソッド）」

この簡単な例からも色々考えることができます。
・鳥オブジェクトを継承したツバメ・スズメも飛べるのか
・それだと同じく継承したペンギン・ダチョウも飛べてしまうのか
・ペンギンは飛ぶではなく水中では泳ぐなのか
・宇宙空間でも飛ぶといえるのか

しかし、
「鳥が飛ぶ」が成り立つと世界では余計な考えが不要となります。
ペンギン・ダチョウは存在せず、水中・宇宙空間でも無いのです。

つまり、オブジェクト指向は“現実の単語”を足掛りに、現実とは異なる世界を構築していると言えます。
私たちはこの行為を「モデリング」と呼んでいます。

「鳥が飛ぶ」とひとつ語るだけでモデリングされた世界の多数の一面を示すことができます。
では普段モデリングされた世界を私たちはどうやって、語ることによって示しているのでしょうか。
そして、どこまでが語りうることの限界なのか、示せれる限界はどこにあるのか。
時間が許す限り「語る」と「示す」の気づきを発表したいと思います。

【概要】
本セッションでは、Go本体のソースコードを紹介しながら、オブジェクト指向プログラミングを解説します。

【背景】
いまやメジャー言語の仲間入りを果たしたGo言語。Go自体のソースコードはGitHubに公開されており、Russ Coxをはじめとする超一流のプログラマが実装に携わっています。そんなGoは構文自体がC言語に近いため、いわゆるオブジェクト指向とは一線を画すと思われがちです。しかし、ソースコードの随所にはオブジェクト指向のプラクティスが幾つか散りばめられています。「Goらしさ」と「オブジェクト指向」が共存したプログラミングの一例をご紹介します。

【こんな方におすすめ】
・ソースコードを見ながらオブジェクト指向を理解したい
・実用（言語処理系）の実装においてオブジェクト指向の使用例を知りたい
※ Goが未経験の方でも解説しながら進行するため、問題ありません

貴方は秘密めいた書籍を拾う、
そのとき、辺り一帯は眩い光りに包まれた。

貴方はオブジェクト概念が無い平行世界に転送されました。
全てのコードにオブジェクトの概念が無いのです、何もかもがコピペされている、そのような世界です。
そんな世界でも最初は何とか生きてこれたが、次第にオブジェクト概念が無いことに苦痛を感じ始めます。
何とかしなきゃ！何とかしなきゃ！
貴方は今まで生きてきたエンジニアの知識を駆使して、このオブジェクトが無い世界に、オブジェクトの概念を広めていこう！

補足:オブジェクトが無い言語が、どうやってオブジェクト構造を構築していくか、それをストーリー仕立てで話していきます。

オブジェクト指向に基づく設計において、メンタルモデルを適切にオブジェクトで表現するために、
オブジェクトの関心や責務を日々意識されているかと思います。

現在私の関わるプロジェクトでは、設計の初期からオブジェクトの責務に対する解像度を上げるため、
要件定義の段階でユースケースを記述する開発プロセスを採用しています。

ユースケースを記述することで、システムが満たすべき振る舞いが明らかになり、オブジェクトの責務に対する理解が深まります。
また、ドメインエキスパートと仕様を議論するツールとしても実用性があります。

対象のオブジェクトが複雑である場合はユースケース記述に加えて、CRCという手法を実施してモデリングをしています。

本発表では、ユースケース記述やCRCを使ったモデリングによるオブジェクト指向の開発プロセスと、
それらを実践している現場のプラクティスをご紹介します。

主なトピック

• ユースケース記述から始める要件定義
• ユースケースを使ったドメインエキスパートとのコミュニケーション
• CRC（クラス、責務、コラボレータ）を使ったモデリング
• DDDに取り入れた事例紹介

今回、（12月時点の）現在進行系で開発が進んでいる案件でLaravelを採用し、
更にドメイン駆動設計の概念を埋め込むような開発手法を取り込んでいます。

しかし「オブジェクト指向」という名前は知っているが内容までは知らず、
かつ古き時代のPHPと現行のPHP7.xの理解が混ざる混沌の中、治水するために奔走した話です。

【概要】

1. PHPとオブジェクト指向：オブジェクト指向の認識を定める
2. ドメイン駆動設計：ドメイン領域を伝え広める（途中経過）
3. ドメイン駆動設計：インフラストラクチャー層、どこまで裁定するか
4. ドメイン駆動設計：形（画面）から入るのを止めさせたかった（失敗談）
5. まとめ：治水、結果は……？

プロダクトのオブジェクト指向が曖昧だったり、
チーム内でドメイン駆動設計を広めようと奮迅されている方への一つの指針としてお伝えできればと存じます。

※若干PHPに傾きよりですが、主題から逸れない内容になっています。

「神クラス」とは、一つのクラスに余りにも多くの機能性を装備してしまい、コードが肥大化した様子を示すアンチパターンである。幾重にもSRP違反になってしまっている状態である。「神クラス」は、幅広いユースケースへ懸命に対応しようとする中で生み出されてしまう。

「神クラス」は、いわゆる業務系システムにて生じがちで、対して、技術的な装置、例えばHTTP Server、複合機の制御システム、などでは生じにくい。

業務システムではなぜ神クラスが出現しやすいか？業務システムのクラスの外部仕様は業務担当者の脳内にある。素朴に客観的に存在するとみなせない。対して、技術的な対象は、素朴に客観的に存在すると見なせる。業務システムでは、系の本質はむしろ利用者（＝クライアント）の脳内イメージそのものなので、系に対する要求発生源を単一に収斂させることができない。

ここに、系のクライアントの脳内イメージを「サブジェクト」と称し、複数のクライアントの「サブジェクト」を調停・統合・合意したモデルを「オブジェクト」と称したとき、いわゆる「エンティティ」は、本質的にサブジェクト－オブジェクトの二重構造を取るというモデルを提示する。

1990年代以降オブジェクト指向プログラミングの普及により、クラス設計、インターフェース設計、GoFのデザインパターンなどが提唱され、近年ではMVC系、DDD、Clean Architectureなどのアーキテクチャの議論が盛んに行われています。

これらももちろん大切ですが言語やアーキテクチャに依存せず、多くのプログラマが必ず検討をする設計として「関数分割」が存在しています。
関数分割の基準については、上記のデザインパターンやアーキテクチャでは議論されていません。

関数の実装は世のプログラマの全員が毎日行うことであり、欠かせない設計であると言っても過言ではありません。

しかし「テスタビリティが高い関数にする」のような基準に留まり、明確に言語化されていることが少ないです。

そこで本セッションではこの関数分割の良し悪しを測る指標として提唱されている凝集度と結合度を紹介します。
これらは構造化プログラミングをベースとした近代の多くの言語すべてに適用できる概念です。

本セッションにでは、以下を理解することができます。

• 7つの凝集度と7つの結合度について
• 関数分割の基準
• レビュー時のレビュアーとレビュイーの納得感
• 凝集度、結合度を理解することで、気がつくことができる見過ごされがちな問題
• 新しく提案されたアーキテクチャが、凝集度や結合度の観点で改善されているということ(近年ではReact Hooksが該当します)

また現実の世界では、論理的凝集と時間的凝集が現場で見過ごされて採用されてしまうケースが多いです。関数にフラグを渡して処理を分岐していませんか？
実際に発生するケースとその問題点を詳細に紹介することで、理論だけではなくより具体的に日常の開発で役立てていただければと思います。

ドメイン駆動設計はオブジェクト指向設計原則のうえに成り立つ設計プラクティスです。

つまり、ドメイン駆動でシステムを設計することは「オブジェクト指向設計をちゃんとやる」ということにほかなりません。検討の対象はクラスだけではありません。もう少し大きな単位、パッケージ／モジュール／レイヤー、まで視野を広げます。

依存関係が注意深く設計され、単一の責任を持ったモジュールやパッケージが、境界付けられたコンテキストをかたちづくります。レイヤーやパッケージの依存関係の逆転により、ドメインは自身の関心の範囲内でビジネスロジックの実現に集中できます。

この発表では依存関係という切り口から、ドメイン駆動なアーキテクチャ設計を継続的に維持・改善していくための手法を、Java とアーキテクチャテストツールの ArchUnit を用いて紹介します。

みなさんは「OOUI」という言葉を聞いたことがあるでしょうか。
これは「Object Oriented User Interface」と呼ばれるもので、アプリケーションのデザインをする上で画面上のコンポーネントとアプリのデータをオブジェクト指向によって対応付ける方法論です。
オブジェクト指向によってもたらされるデータとアクションの整理された構造がUIに反映されることで、OOUIはユーザーにより分かりやすい直感的な操作性をUIとして提供します。

本セッションでは、例として1つのアプリケーションを取り上げて、オブジェクト指向ベースでオブジェクトを抽出してUIを設計していく中で、OOUIがどのようなプロセスで構築されていくのかを具体的に説明します。

複雑なシステムの設計を行う際には、そのシステムを様々な観点（ビュー）を通して観ることで、そのシステムを構成するコンポーネントを把握することが重要です。それらの各コンポーネントがどのような責務を担い、周囲のコンポーネントとの間でどのような相互作用を期待するかを整理することが堅牢なシステムの実現に繋がります。コンポーネントが責務を持ちそれらの相互作用で大きな価値を提供する構造は、まさにオブジェクト指向の世界観と重なります。

本セッションでは、Webアプリケーションを１つのシステムとみなして、それを構成する複数のコンポーネントをどのように分割し、どのような関係性に整理するのがよいか考える過程をお話する予定です。具体的にはアプリケーションを支える基盤的な横断的関心事を題材に、モデリングを通じて責務を整理していく予定です。

本セッションを通じて、オブジェクト指向をプログラミング以外の場面でも活用できるイメージを持ち帰って頂けると嬉しいです。

※ショートセッションで採択の場合には、実践例を中心にご紹介したいと思います。

DDD、という単語を昨日まで知らなかった自分がいきなりBounded Contextを探すことになった。

超展開でDDDの世界に引き込まれ、社内に有識者がいるのかも分からない状況から戦略的DDDをやった話をします。
大まかなアジェンダは以下を考えています。
・そもそもDDDって？
・実際にドメインを分割する活動の中でやったアプローチの紹介
・私なりに戦略的DDDをやった結果わかったこと

DDDの本はとんでもなく分かりにくいし、戦略的DDDの部分は特に抽象的すぎてもはや何が書いてあるのか全く分かりませんでした。
もちろん、どう実践すればいいのかなんて全く分からず、途方に暮れていました。
このトークを通じて、戦略的DDDがやりたい、知っているけど最初何したらいいか分からない。という方の悩みが解決できればと思っています。

したがって、実際にやったこととその振り返りをメインで話します。
具体的には、以下の内容と分かったことを詳細に話します。
・本を読む。ネットサーフィンする。
・twitterでDDDで有名な人にいきなり質問をして得られたリプライのご紹介。
・自作のワークショップを企画してやってみる。
・休日に人を集めてEventstormingとやらをやってみる。

戦略的DDDの理論についてはなるべくシンプルに説明し、実際にとったアプローチを中心にお話しようと思います。
イメージがしやすく、最初の一歩が踏み出しやすいよう、なるべく具体的に話します。よろしくお願いします！