トーク

「良い設計」は「良いアプリケーション」をつくるための重要な要素であり，オブジェクト指向はそれを実現するための道具の1つです。
継承，カプセル化，多態性の三大要素を活用して，保守性や再利用性などを高めることに注力します。

しかし，我々が普段扱うOSやミドルウェアの多くは実装にC言語を使用しています。
C言語はオブジェクト指向を実現することを想定した仕組みを持っていません。
それでも，低レイヤのコードにもオブジェクト指向の考え方に基づいた設計と実装が確かに存在します。
これは，「ある機能を実現するための設計が結果としてオブジェクト指向になったもの」と捉えることができます。
このような設計や実装に注目することで，「手段」としてオブジェクト指向を用いる際の本質が見えてくるのではないでしょうか。

本セッションでは，一般に使われているOSSのコードを例に，C言語を用いたオブジェクト指向設計の実装を紹介し，設計の意図やユースケースに合わせた妥協点を探ります。
普段とは少し異なる視点からオブジェクト指向を眺める機会をつくり，低レイヤ領域に興味を持つきっかけになれば幸いです。

※C言語や周辺知識の複雑な部分は都度解説するため，コアな知識は不要です。

【このセッションでお話すること】
・設計と実装，手段と目的の再確認
・C言語でオブジェクト指向を実現する基本戦略
・一般的なOSSの設計と実装の紹介
・まとめ 他の言語に生かすために

「自社サービスの成長に伴いシステムのリニューアルを繰り返してきました。
実装プログラマーの増加、サービス利用ユーザー数増加に伴い都度システムの再設計を行ってきた経験を共有します。
サービスリリース当初、エンジニアは私ひとりでした。
何よりもサービスを早くリリースすることを優先し、後から見返すと共通化できる処理がコピペで複数存在しているとてもカオスなプログラムソースでした。ControllerやModelは肥大化しまくりですが、サービスを止めることはできません。

プロダクトに関わる人が増えるにつれ技術的負債にフタをすることに限界がきます。
サービス利用ユーザー数が1万人を超えたあたりから本格的にリニューアルを行い、システムも再設計しました。
2万人を超えたあたりからノウハウも溜まり、満を持してリリースした新サービスではクリーンアーキテクチャを意識した設計、新しい技術挑戦を行なっています。

時系列形式で考察した過程、経験から得たメリット・デメリットを赤裸々に紹介します。
スタートアップ向け、新規事業開発向けのセッションになります。」

[キーワード]
スタートアップ、新規事業、MVC、ADR、ADM、DDD、クリーンアーキテクチャ、SPA、CakePHP、Laravel、vue.js、Nuxt、aws

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

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

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

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

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

主なトピック

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

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

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

【概要】

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

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

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

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

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

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

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

昨今のシステムは、社内外のシステムと連携していて境界定義が難しいといわれています。だから、大きなシステムは人間が制御できるぐらいのサービスに分割する。それがマイクロサービスの考え方の一つです。こういったシステムを分割して構造化する手法は古くから「モジュール化」という手法が有名です。マイクロサービスは現代のモジュールだと考えています。そして、このモジュールは技術的観点よりビジネス的観点で分割したほうがよいといわれるようになりました。具体的にはドメイン駆動設計の「ドメイン」です。これらの「モジュールとしてのマイクロサービス」と 「分割単位としてのドメイン」はシステム設計を語るうえで重要なキーワードです。今回は、モジュール化とドメインの関係性について考察したいと思います。

オブジェクト指向言語によって作成されたアプリケーションでは、ごく限られた例外を除き、インスタンス化されたすべてのオブジェクトはいずれゴミとして消えゆくことが運命づけられます。
今日、多くの言語においてこれらオブジェクトのライフサイクル管理は自動化されており、「オブジェクトがメモリを使う」「オブジェクトが生きている」といった事実への関心が失われつつあるのではないでしょうか。
自動管理の恩恵を享受するあまり、私たち多くのエンジニアは気軽かつ無秩序にオブジェクトを生成しています。
その代償として、時折アプリケーションはメモリリークという牙をむき、私たちに襲いかかります。
このセッションは、普段注目されることの少ないオブジェクトライフサイクルとメモリ管理について、改めて思いを馳せることを目的にします。
オブジェクトが生まれてから消えゆくまでどのような流れをたどるかに着目し、メモリ管理の実装について初心者に向けて解説したいと思います。

Mathematicaは、項書き換え型言語と呼ばれますが、オブジェクト指向言語であるとはされていません。しかし、実は、基本的な関数の組み合わせだけで、一切のスクリプトを用いることなく、OOPを実現することができます。その核心部分がMathematicaで記述された関数の二重呼び出しです。
実現されたクラスそして内部に置かれるメソッドは関数型で表現されるゆえに、コンストラクションはクラス関数の呼び出しとして表され、結果としてインスタンスも関数型で表現されます。
関数型として表現されるゆえに、コンストラクションには連想配列（辞書型）を極めて容易に導入でき、メモリの許す限りの多数の初期化されたインスタンスを生成することができます。
このトークで、たとえMathematicaを知らなくとも、OOPがどのように構成されているかを知ることができます。なぜならば、Mathematicaの関数によりOOPを構成していく過程を見ることで、クラスとメソッドはどのような関係にあるかを知り、どうしてカプセル化が実現されるのかを知り、クラス関数の実行でコンストラクションとインスタンスの関係を知り、複数のクラスの関係から継承とは何かを知り、関数呼び出しの形式からポリモルフィズムを知ることができるからです。ラムダ計算を通じて、クロージャがOOPに包含される様子も目にすることができるでしょう。
そして、OOP環境が関数型として表現されるゆえに、強力なMathematicaのソルバーやグラフィックスと容易に組み合わせることができて、さらには、インスタンスをマルチコアにデプロイすることで並列計算への扉が開かれることを、実例でお示ししましょう。

現在、UMLなどで作図できるモデリングツールとして、さまざまな
ツールが利用されています。しかし、ツールベンダーから見ると
「モデリングツール」と、PlantUMLやVisioのような「作図するためのツール」との
区別がなく、どちらも同じような位置づけのツールと考えている人が
少なくないと感じられます。

この背景として、「モデリング」とはどのようなものか、という認識が
人によって異なることがあるように思います。

このセッションでは、「モデリング」には、大きく分けると2種類の位置づけが
あることを、まずお伝えしたいと思います。
そして、「作図ツールとモデリングツールはどのように違うのか」および
「モデリングツールにはどのような価値があるのか」について、
実際のデモを通して伝えたいです。

デモの題材として、UMLおよび、神崎善司氏によるモデルベースの
用件定義手法であるRDRA2.0を利用します。

「作図ツールとは違うのだよ、作図ツールとは！」

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

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

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

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

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

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

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

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

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

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

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

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

オブジェクト指向プログラミングの歴史を振り返りながら、現在の状況と今後の方向性について考えてみます。

• 黎明期
• GUIとオブジェクト指向ブーム
• UMLとオブジェクト指向モデリング
• アジャイルムーブメントとオブジェクト指向プログラミング
• 関数型プログラミングとオブジェクト指向プログラミング
• ドメイン駆動設計とオブジェクト指向プログラミング
• マイクロサービシズとオブジェクト指向プログラミング

かつては、オブジェクト指向の本質といわれたものが、いまでは、わき役になったり、アンチパターンとされるものもある。
そういう流れの中で、これからのオブジェクト指向プログラミングは、どういう方向に進む可能性があるのか、考えてみましょう。

優れたシステムは直面している課題を的確に解決し、その課題の要因へ繋がるさらなる課題提起へ導きます。ビジネス、システム、コードなど、いくつかのレイヤーをオブジェクト指向でとらえ、高い価値を提供するためのアプローチについて話します。

オブジェクトとは一体何でしょうか？

モデリングパラダイムとしてはオブジェクトの他にもデータモデルの設計によく使われるERモデルやリレーショナルモデル、または関数型言語のベースになっているラムダ計算などがあります。

それぞれのモデリングパラダイムには得意な表現/苦手な表現があり、本来は解決したい問題領域によってそれらを選択することが好ましいのですが、実際には多くの開発者が、クラスや関数、RDBのテーブルなどといった具体実装や言語機能/ミドルウェア機能に着目しやすく、モデルそのものの表現力について議論されることが少ないように感じています。

温故知新と言われるように、進化し続ける現代のソフトウェア技術の中にいる我々にとっても古くからあるこれらのモデリングパラダイムやそれを切り開いてきた先人たちの思想は学ぶ価値のあるものであり、その上でハードウェアが進化した現代においてそれらのモデルをどのように活用していくかが我々に求められている課題だと考えています。

本発表では、先人たちの思想をなぞりながら、オブジェクトが目指したものは何だったのか今一度再考し、その他のモデリングパラダイムとの共通点・相違点について述べていきます。また、異なるモデリングパラダイムの間に生じてしまうインピーダンスミスマッチをどのように最小化していくかについても一緒に考えていきたいと思います。

以下のような先人たちの名前にピンと来る人はぜひ聞きに来てください。（注: とりあげる人物は予告なく変更になる可能性があります）
アラン・ケイ、ストラウストラップ、バートランド・メイヤー、エドガー・F・コッド、クリス・デイト、ピーター・チェン
※ また、上述したようなモデリングパラダイムの直接の提唱者ではありませんが、ジェームス・コプリエンやリッチ・ヒッキーらの考えについてもとりあげます。

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