Object-Oriented Conference概要
※イベント及びセッションの概要は公式HPから引用しました。
2020.02.16 SUN 10:00 - 17:00 お茶の水女子大学
#ooc_2020
Object-Oriented Conference はオブジェクト指向をテーマに、あれこれ共有したり、セッションを聴講することで、みなさんの知見を深めるためのイベントです。
オブジェクト指向といっても、分析設計から、現場で活かすためのプラクティスなど様々なテーマがあります。セッションやラウンドテーブルなどを通じて、参加者の皆様が新たな発見を持ち帰っていただけるようなイベントを目指しています。
オブジェクト指向についてまったく知らない方やオブジェクト指向を完全に理解した方、そして普段オブジェクト指向以外のパラダイムを利用している方もお気軽にご参加ください！
開会の挨拶
-
オブジェクト指向が好きだから開催
-
「開催されたこと」に価値がある
-
CFPの倍率3倍くらい
- オブジェクト指向に関連のあるものを選ばせていただいた
- 設計、モデリング、要件定義、哲学
-
とにかく楽しんでください！
-
※以下は@akrwtnkが参加したセッションのみを記載しています
keynote: Object-Oriented Diversity
11:15〜 共2-201 keynote
優れたアイデアからは連鎖的に、新たなアイデアが創造されます。
いまやオブジェクト指向は大きな広がりを見せ、世の中にはオブジェクト指向に端を発したアイデアが次々と生み出されています。
人に個性があるように、それらのアイデアにはそれぞれ個性があります。
それらをすべてまとめあげ、ひとつのオブジェクト指向として扱うのは難しいことでしょう。
本トークは「オブジェクト指向の多様性との対峙の仕方」をテーマにします。
オブジェクト指向が多様性をどのように取り扱っているかをヒントに、
オブジェクト指向自体の多様性とどのように付き合っていく術についてお話いたします。
オブジェクト指向に関わらず、あるアイデアから多様な価値が生まれ、それらが同じ文脈で語られることで混乱をきたすような場面を多く見かけます。
本トークはそういったものとの対峙法のひとつとして活用できるでしょう。
メモ
- Object-Oriented Divercity
- あなたのオブジェクト指向はなんですか？
- 一つのアイデアから多くのアイデアが生まれること
- いま、広がっている。これが優れたアイデアに共通している。
- すごくいいこと。
- しかし、光があれば闇がある。
- 闇の話
- オブジェクト指向の話をしているときに「なんか違うな」「それオブジェクト指向じゃないよね」「いやオブジェクト指向だよ」戦争
- 抽象データ型、メッセージパッシング
- 発生からしてオブジェクト指向はややこしい。だからこそ行き違いが起きる
- そこでDivercity
- 多様性
- うまく扱うには？
- ポリモーフィズム
- 中身が気になったら来歴を調べる
- インターフェースとしてのオブジェクト指向
- ポリモーフィズムなんの役割なんだろう？
- 文脈の表現
- コンテキスト
- IT技術分野には多くのコンテキストがある。
- モデル
- 事象、データ
- エンティティ
- ER図、識別子
- ドメイン
- コンテキストが存在することを意識しよう
- モデル
- UserContext
- HttpContext
- 重要なのはどのコンテキストなのかを意識すること
- IT技術分野には多くのコンテキストがある。
- 多様性をうまく扱おう
- 多様性を恐れないために
- マサカリではなくて、小学校の教室
- 質問が出ることをポジティブに捉えて欲しい
- 質問の見え方が変わってくる
- 来歴を確認すること
- 多様性
- あなたのオブジェクト指向はなんですか？
感想
- 「IT技術分野には多くのコンテキストがある」「コンテキストが存在することを意識しよう」というのは最近なんとなく考えていたものの、捉えきれておらず言語化できていなかった。成瀬さんのお話を聞いたことで、それらがスッと掌に乗った感じがする。
関心の分離って何？
11:50〜 共2-201 ロングセッション
オブジェクト指向の設計において「関心の分離」「責務」が重要と語られている。さらに昔からモジュール設計においては「凝集度」と「結合度」が大事だと言われてきた。一方エリックエバンスのDDDでは、ユビキタス言語としてのドメインモデルを使って、ドメインエキスパートとコミュニケーションを図ることが大事だとしいる。つまり、「関心の分離」は要件から仕様化・設計・実装・テスト、さらにアーキテクチャ構築までの一連の活動に関わっている。
今回は「関心とは何か？」「責務との違いは？」など「分ける」ことについて、オブジェクト指向と関数型のマルチパラダイムの視点を加味して、簡単な思考実験を行いながら、物事の捉え方を体感します。
さあ、この無謀とも思える思考実験。「吉」と出るか「凶」と出るか。
モデルベースの用件定義手法であるRDRAをまとめていく時に使った「境界を引く」考え方を説明しながらトライします。
メモ
- 混乱しているものからは混乱しているものしか出てこない
- 整理しなければ整理されたものは出てこない
- 対象の捉え方が今回のテーマで、テクニックは扱わない
- 関心ごと
- 「仕様と仕組み」
整理できない
- なぜ整理できないのか
- 例
- 大根の売り上げは気になるし、1本と半分の場合の売り上げが気になる
- 加工食品を扱う
- 徐々に広がっていき、ちゃんと整理されていない。
- 例
混沌からの脱出
- 修正が簡単なのは
- 何に着目しました？
- 影響範囲が広いのはどれか
- その変更は局所化しているか
- 何に着目しました？
- 関心ごとと要求への対応が問題の局所化につながる
- 関心ごとは仕様と仕組みに分けて考える
- 機能要求：仕様としての関心ごと
- 機能
- プロセス
- 処理対象
- 機能
- 非機能要求：仕組みとしての関心ごと
- 手段
- コンセプトが手段を選択する
- 手段
- 要求から全ての関心ごとが出てくるわけではない
- 機能要求：仕様としての関心ごと
仕様としての関心ごと
- 対象の捉え方
- どんぶりの視点
- 様々な変化の中の普遍的な構造を捉えようとしている
- 関数の視点
- 普遍的なものについては関心がないが、入力と出力の変換に関心がある
- どんぶりの視点
- 問題領域
- プロセス的視点
- 構造的視点
- 構造的視点で見ているのがオブジェクト指向
- どんぶりは自明だが、明示できるものではない
- 分ける
- どう分けた？
- どうまとめた？
- 何に着目した？
- 物置に収納する場合は？
- 要求(関心ごと)：より多く収納する
- 小さくする
- 重ねる
- 折りたたむ
- 安定する置き方
- 小さくする
- 要求：出し入れしやすい
- 要求(関心ごと)：より多く収納する
- 店頭で売るとしたら？
- 顧客の興味
- 見つけやすさ
- 分ける
- 対象が同じでも目的によって関心が変わる
- 対象を正しく捉える
- 環境に着目して「関心ごと」に気を配る
- 質問の質が変わる
- 構造を捉えるための意識が変わる
- 関心ごとが変更起点になる
- 変更の起点となるもの(ビジネス的に出てくる変更に限定した話)
- 入出力
- ビジネスルール
- 変更起点の分析は企業の特徴を分析することにつながる
- 変更の起点となるもの(ビジネス的に出てくる変更に限定した話)
- 関心ごとの局所化に向けて
- ワンファクトインワンプレイス
- DOA
- 1仕様を1箇所へ
- ワンファクトインワンプレイス
- 仕様としての関心ごとを掘り起こす
- 表
- 気づきのヒント
- 雛形持っとくといいよ
仕組みとしての関心ごと
- アーキテクチャの話
- ビジネス系のプログラム
- ライブラリ間の変換ばかりやっている
- 仕様が様々な変換に紛れ込む
- トランザクションスクリプトはこの構造に素直に従ったもの
- 整理したいですね
- 仕様と仕組みの分離
- 仕様は仕様で構造化、仕組みは仕組みで構造化
- 仕組みの関心ごと
- たてつけ
- 非機能要求から関心ごとは生まれる
- 非機能要求はしばしばコンフリクトする
- このコンフリクトをどう扱うか
- 非機能要求はしばしばコンフリクトする
- 開発生産性を上げる
- 鶴を早く折れる人は誰？
- 折ったことない、一回折った、何回も折った
- 同じことを繰り返せば速くなる
- 折ったことない、一回折った、何回も折った
- 違うものをどのように同じものとして扱えるのか
- 鶴を早く折れる人は誰？
- 違うものを同じように扱う
- オブジェクト指向のアプローチ
- 構造的視点で抽象化
- 関数型のアプローチ
- プロセス視点で抽象化
- 共通的な文脈を洗い出す
- 共通処理の洗い出しではない
- 共通的な文脈を洗い出す
- プロセス視点で抽象化
- オブジェクト指向のアプローチ
- 収納という文脈において抽象化を考える
- オブジェクト指向のアプローチ
- 小さくする、安定に関心
- 構造的に違うものを同じように扱えるようにする
- 関数型のアプローチ
- 変換に関心。重ねる
- 異なるプロセスを同じように扱えるようにする
- どこに着目しているもか
- オブジェクト指向のアプローチ
- システム全体をどう見るか
- システム全体：オブジェクト指向
- 部分：関数型
- 例
- エクセルの定義をパワポのモデルに変換するツール
- 例
感想
- 大学の授業(の中の興味深い授業)を受けているようで良かった。
- 「開発生産性を上げる」の鶴の例は、長期的な視点で見たらT_WADAさんの「質とスピード」にも繋がるものがあるかもと思った。
- 成瀬さんの基調講演の「コンテキスト」という言葉が早速出てきていいな〜と思った
Chatworkのドメインをモデリングした
12:50〜 共2-201 ランチセッション
2011年3月にリリースされたChatworkも今年で9年目となり、その間、何度もリファクタリングとリアーキテクティングを繰り返してきました。
長く運用されているシステムらしく様々なレガシーと呼べる要因を抱えており、リライトを視野に入れた取り組みに挑戦しています。
その挑戦の過程において、Chatworkのドメインをモデリングすることに取り組みましてので、どのように実施したのか手順や使ったツール、観点などをご紹介できればと思います
メモ
目的
- チャットワークの現状を把握して理想のモデルを描く
レガシーを掘り起こす
- システムコンテキスト図
- RDRA2.0でトップダウン
- システムに関係するアクターと外部システムを洗い出す
- 個人名が出てきたりと属人化している部分も見えてきた
- 早く失敗することを優先
- インタビューしつつ、図に落とし込んでいった
- 全ての業務ってどれくらいあるのだろう
- データ構造の分析
- 正規化されていない
- どこまでが意味のあるまとまりなのかを探るために、構造をJavaのクラスに落とした
- そのままの構造は、人が理解するには難しすぎた
- どこまでが意味のあるまとまりなのかを探るために、構造をJavaのクラスに落とした
- 正規化されていない
- 言葉を定義する
- 既存の言葉の意味を調べる
- 「つまりこうだよね」って言葉を整理する
- 言葉のリファクタリング
- パッケージにまとめる
- ユースケースで検証する
- Roleオブジェクト
- DCIアーキテクチャ
感想
- レガシーに立ち向かうためにはどのようなものが眠っているのかを紐解いていく必要があり、
そのための方法はいろいろあるのだなと思った。
VOYAGE GROUP流開発文化
13:10〜 共2-201 ランチセッション
VOYAGE GROUPでは複数のサービスを提供していますが、ほとんどのプロダクトが自社開発です。VOYAGE GROUPのエンジニアはサービス全般に責任を持っているため、ドメインエキスパートであり、開発者であり、サービス運営者でもあります。
幅広くビジネスに対して責任を求められる中、弊社のエンジニアはどのように考えてシステムを設計しているのか、どのような取り組みを行っているのかなど、ビジネスを成長させるためにVOYAGE GROUPが行っている仕掛けをいくつか例を上げて紹介いたします。
メモ
- 事業に最適な技術をチーム毎に選択
- 技術力評価会
- エンジニアがエンジニアを評価することで、継続的に成長できる仕組み
- 評価者は2名
- 具体事例
- unioさん
- レポート機能の作成
- 見よう見まねでサービスを作ったが
- 意図を理解しよう
- DDD
- 『ドメイン駆動設計』
- DDD
- ヒアリング＆検討を何度もループ
- 意図を理解しよう
- 見よう見まねでサービスを作ったが
- 新レポート機能
- DDDによく出てきている単語が出てきている
- 再設計に近かった
- 「必要最低限かつ拡張しやすい設計」を目指しましょう
- 拡張しやすい、というのが重要
- レポート機能の作成
- unioさん
- エンジニアもサービスも成長
感想
- 「必要最低限かつ拡張しやすい設計」という視点はQAとしてもどこかで活かそう。
- すぐ思い浮かぶのはテスト設計
READYFORにおける複雑なドメインとレガシーシステムとの戦い方
13:30〜 共2-201 ランチセッション
READYFORは、2011年に日本初のクラウドファンディングとして始まったサービスです。我々は「誰もがやりたいことを実現できる世の中をつくる」というビジョンのもと「想いの乗ったお金の流れを増やす」ためのプロダクト開発を日々行なっています。そのような新規開発をスピーディーに推し進める上でも、9年間積み重ねてきたレガシーとしっかりと向き合い、戦っていく必要があり、そのための武器の一つがDDDだと考えています。本セッションでは、READYFORにおけるドメインや既存システムの複雑さを解説し、DDDを用いてどのようにして境界づけられたコンテクストやユビキタス言語を構築し、理想のシステム像を設計した上でリファクタリングを推し進めていこうとしているかをお話しします。
メモ
- READYFOR クラウドファンディング
- ドメインの複雑さ
- 「プロジェクト」のライフサイクル
- 実行者が初めて、支援者が支援
- 実行者と支援者の間の業務フローが複雑
- 様々なコンテキスト
- 実行者が初めて、支援者が支援
- 「プロジェクト」のライフサイクル
- 巨大モデルのつらみ
- 責務の分離できていない
- 密結合
- 変更厳しい
- 境界づけられたコンテキストを理解する
- DDDの戦略的設計の概念の一つ
- READYFORのシステムを境界づけられたコンテキストから理解
- これでプロジェクトモデルの責務分離可能では…？
- リファクタリングどうする
- 技術的負債
- BSのアナロジーとしての技術的負債
- ソフトウェアとしての価値＝技術的純資産＋技術的負債
- 実は技術的負債は資産の一つ。絶対悪ではない。どう対処するかがだいじ。
- 技術的負債に対して技術的純資産が多い場合
- 技術的純資産よりも技術的負債が多い場合
- リファクタリング
- 軸に添えるのはドメイン駆動設計
- BSのアナロジーとしての技術的負債
- これでプロジェクトモデルの責務分離可能では…？
- ドメインの複雑さ
感想
- 「境界づけられたコンテキストを理解」は意識していく。
数理的システム設計-ビジネスと技術制約を繋ぐ手法-
14:00〜 共2-201 ロングセッション
ビジネスとしても技術としても合意できる、ビジネス対して十分な拡張性を持ったシステムアーキテクチャがほしい。
これを実現するために設計手法をつくってみました。数理的システム設計と呼んでいます。
自分が作りやすい、自分がマネジメントしやすい「やりやすい設計」を避けるための手法となります。
これは既存手法とは異なり、システムレベルでのよい設計をめざすものです。
この実現のために、パタンランゲージの始祖であるクリストファーアレグザンダー氏の理論をソフトウェアシステム設計に取り入れました。
まずシステムレベルでの分析と設計においては、15の幾何学的特性(美しい設計の根源には15の幾何学的な特性があるとアレグザンダーがみいだしたもの)を活用します。
全体性を重んじ、全体と部分をいったりきたりしながら、設計をすすめていきます。そして、その後にパタンランゲージを適用していきます。
メモ
- こういう事例もあるんだな程度に聞いてほしい
- アジャイルとクラウドの普及
- 分散システムの採用が増える
- システム/コンポーネント分割の基準を教えてください
- よく見る負債
- やりたいことの可能性との乖離
- プランBの不足
- 新技術に追従できない
- 解決策
- リファクタリングは大きな変更に耐えられない
- 作るものを最小化してフィードバック
- DDD
- システム全体の最適化はできない
- クラウドアーキテクチャは現状の技術に依存している
- な座これらの手法では難しいのか
- 1要件
- 2クラウドアーキテクチャ
- 3アプリアーキテクチャ
- 4実装
- 5監視
- 1と2は、もっと遅延しても良いのでは？
- 現状の課題に対する仮説
- ビジネス要求と物理的なアーキテクチャをつなぐ重要性が増しているが、既存手法では難しい
- こうだ
- 1要件
- 数理的アーキテクチャ
- 2クラウドアーキテクチャ
- 3アプリアーキテクチャ
- 4実装
- 5監視
- 技術やユースケースに依存した設計は負債が大きすぎる
- 構造を決定しない
- 「絶対に変化しない何か」
- 美しさ
- 良い建築とは
- 良い設計とは
- ネイチャーボーダー？
- 15の幾何学特性
- 保守性が高いとは
- 手戻りが少ないこと
- 普遍性の高い何かに依存して設計することで設計の手戻りを減らす
- 手戻りが少ないこと
- 数理的システムアーキテクチャ設計
- 論理的なシステムができて、現状のシステムのギャップを把握しやすくなる
- 機能を配置する場所が限定されやすくなる
- 技術変化に追従しやすい
- ステップ
- 1定量化できる普遍的な何かを軸にする
- 軸を見出すためには、ユーザーストーリーマッピングなど
- コストでする、主観的にするのはアンチパターン
- 2必要な部分や全体を見出していく
- 3非機能要件を当てていく
- 1定量化できる普遍的な何かを軸にする
- プロセス例
- 9
- 用いる軸は3軸
- 何故このようなつながりで考えているのか
- 生きながらえることがいいことだと伝えている
- メッセージ、センター、間
- アランケイ、クリストファー、アレクサンダー
- 生きながらえることがいいことだと伝えている
- 先の箱は、サブシステム/コンポーネントではない
- ドア
- 部屋の仕切り
- ゲートウェイは部屋の仕切りに意味を見出している
- 必要な切り方がそこにある。構造を決めているわけではない
- そのような間があると美しい
- Ma-Oriented
- インターフェースの決定を遅延し、構造の決定を遅延させるをどの段階でもやりたい
- 課題
- ここから物理アーキテクチャに落としにくい
- 重力のような支配的な法則を発見できていない
- 「これはここにあるべきだ」というような絶対的なもの
- まとめ
- ビジネスで普遍的で数値比較可能で重要な軸によって全体から部分を見出すことにより、システムの大枠を見極めやすくなる。
- これらにより技術依存によって生まれた部分と、論理世界における部分のギャップを認識しやすくなり、昨日は一夜技術追従の際に、ビジネスの目的に合わせて考えやすくなる。
感想
- もう一度スライドを見直す
- まだ私自身しっかり理解できていない部分もありそうだが、建築などの(エンジニア的にみた)技術に直接的に関連のないことから方法論や法則を見出すというのは面白いなと思った。
アジャイル時代のモデリング
15:00〜 共2-201 ロングセッション
モデリングのパワーを活かしながらアジャイルに開発を進める、軽量モデリングの手法を提案します。
アジャイル開発では、動くコード（そして自動化テスト）が重要な成果物として扱われます。では、設計はどこに行ったのでしょう？モデリングはもういらない？UMLは死んだ？ぼくはそう思いません。
"The code is the truth, but it is not the whole truth." -- Grady Booch
このセッションでは、アジャイル時代に相応しいモデリングの役割について探ってみたいと思います。合わせて、海外で話題の軽量モデリング手法、 C4 Model の概要もお話します。
メモ
アジャイルとデザイン
- コードとテストがあればいいのか？図を使おうよ。という回帰
- ビジネスとのバランス。ビジネスとコードが共に成長するには？
- INPUTとOUTPUTの間にデザインという言葉がない
- 知見としてどう残していくのか
- Graby Booch
- 成長し続けるが、一貫した美がある。
- 美を繋ぎ止めている力
- アジャイルが嫌ったもの
- Design Upfront
- 実際はほぼ要らないもの
- 設計してみる作ってみる設計してみる
- NDUF BDUF
- アーキテクチャのスイートスポット
- アーキテクチャに時間を使えば使うほどコストはかさむが、後の修正は抑えることができる
- コンテキスト次第でスイートスポットは変わる
- 『アジャイルと規律』
- アジャイル適正
- 『Design it！』
- 『アジャイルモデリング』
- 水を流してはいいけど赤ちゃんを流すな
- Design Upfront
- なぜモデルを使うのか
- 絵で描ける
- CAKE WRECKS
- 盲人模像
- 全体感をどう捉えるか
- 絵で描ける
モデル
- 共通理解を作るために、一番シンプルなモデル
- モデルを分ける
- 残すもの：KEEPS
- アーキテクチャ
- 変わるかもしれないが、メンテナンスして保存しておくべきもの
- ドメインモデル
- ユーザーと対話するための言葉
- キーユースケース
- ユーザーのインタラクション
- 実現するための仕組み
- キーとなるもの
- アーキテクチャ
- 捨てるもの：TEMPS
- カジュアルモデリング
- ホワイトボード
- カジュアルモデリング
- 残すもの：KEEPS
- モデルを分ける
アーキテクチャ、ドメインモデル、キーユースケース
- アーキテクチャ
- システム全体の構造的な表現
- 『ソフトウェアアーキテクチャ』
- パッケージの依存関係の逆転に注意
- システム全体の構造的な表現
- ドメインモデル
- 「寿司」のドメインモデル
- マインドマップで整理したり、ビジュアルに表現するとパッと分かる
- キーユースケース
- ユーザーから見たシステムの代表的な使い方
- 誰がユーザーで、何が嬉しいのか
- そのゴールを得られるまでのアーキテクチャを貫通するメカニズム
- 制御の流れ
- 開発者には教育的な例示となる
- ユーザーから見たシステムの代表的な使い方
- KEEPの上にTEMPを重ねる
知識をスケールする
- ケント・ベックの言葉
- XPでは動く実装を1個作ってから分割
- 最初から分割するのではない
- 実装とモデルを作って、村を作る。村を作ってから分割。
- Craig
- モデルを使ってConversation
- 成果物としてのモデルは減らしたいが、コードから漏れてしまうような知識は残しておきたい。
- 他にも残しておきたいものはないか
- なぜこのフレームワーク、テクノロジを選んだのか
- ADR
- アーキテクチャデザインレコード
- インパクトマッピング
-
@simobrownさんの手法
- 最も分かりやすい言語化
- 階層
- システム
- コンテナ
- コンポーネント
- コード
- コンポーネント
- コンテナ
- システム
- Notation
- 凡例を書いておく
- テキストのみでも分かるように
- 図の種類も含める
- Abstractionが先Notationはあと
- ユビキタス言語がだいじ
- モデルを使ってConversation
- Graby Booch
- 人伝に継承されている
- 式年遷宮
- 世代間を超えた部族記憶
- 壊して持っていく
- 新たなツールも
- 再生できるように繋いでいる
- 人間のTribal Memoryがだいじ
感想
- 「寿司」のドメインモデル面白い
- モデリングの練習として「寿司」のような身近な題材で考えてみるのはいいなと思った
- ADR初めて知った！
- これはテスト設計するときになんとなく意識していたが、名前がついているとは思わなかった。
「モジュールとしてのマイクロサービス」と 「分割単位としてのドメイン」について考える
16:00〜 共2-201 ロングセッション
昨今のシステムは、社内外のシステムと連携していて境界定義が難しいといわれています。だから、大きなシステムは人間が制御できるぐらいのサービスに分割する。それがマイクロサービスの考え方の一つです。こういったシステムを分割して構造化する手法は古くから「モジュール化」という手法が有名です。マイクロサービスは現代のモジュールだと考えています。そして、このモジュールは技術的観点よりビジネス的観点で分割したほうがよいといわれるようになりました。具体的にはドメイン駆動設計の「ドメイン」です。これらの「モジュールとしてのマイクロサービス」と 「分割単位としてのドメイン」はシステム設計を語るうえで重要なキーワードです。今回は、モジュール化とドメインの関係性について考察したいと思います。
メモ
テーマ
- 境界定義が難しい
- マイクロサービスの文脈でも同様
- 部品＝モジュールで、モジュールもオブジェクトの一種
- モジュールとドメインにはどんな関係があるのか
マイクロサービスアーキテクチャ(MSA)とは
- 単一のアプリケーションを小さなサービス群を組み合わせて構成する設計手法
- ビジネスの関心ごとで分かれていくイメージ
MSA以前の問題とは
- 変更の影響範囲
- 一枚岩だと変更の影響範囲を特定するのに時間がかかっていた
- テストの広範囲になりがち
- 同時並行に機能変更すると影響範囲の特定がさらに難しくなる。
- 場合によっては逐次的に変更を管理する必要があり、これが小さな変更でも時間がかかる理由
- 分業形態に関わる問題
- 技術的観点で組織を分割してきた
- 要求に合わせて適切な技術選択が難しい
- 技術の選択権がないと優秀なエンジニアはやる気をなくす問題もある。自治権が与えられない
- 技術的観点で組織を分割してきた
MSAでモジュール構造がどう変わったのか
- 内部モジュールがコードやDBも共有しない独立した「コンポーネント」となった
MSAの特徴
- サービスを通じたコンポーネント化
- コンポーネントは古くの言い方だとモジュール
- モジュール化を温故知新で掘り下げてみる
- 個々の部品がモジュール
- 例：数の加算的グループの部分集合でそれ自身が加算的グループであるもの
- 入れ子。マトリョーシカ的な
- 例：数の加算的グループの部分集合でそれ自身が加算的グループであるもの
- モジュール化のコア概念
- ①モジュール内では相互依存し、モジュール間では独立している
- 疎と密が必要
- 境界が必要
- アーキテクチャ
- ②情報が隠蔽されている
- 複雑な知識には触れずに労力だけを得る
- ①モジュール内では相互依存し、モジュール間では独立している
- モジュールの設計概念
- 明示的なデザインルールと隠されたデザインパラメータ
- 事前合意が必要
- 外と中にあるものを区別
- 明示的なデザインルール
- アーキテクチャ
- インターフェース
- 標準
- 隠されたデザインパラメータ
- そのモジュールを超えて、他の設計に影響を及ぼさない意思決定
- 選択を遅延できるし交換可能だし他のチームとの相談もしなくて良い
- デザインルールがFail Fastを支えた例
- IBM/System 360
- 企業は単一のモジュールに集中し、より深く追求できた
- 広範なアプローチを自由に試みることができた
- IBM/System 360
- モジュールがアジャイルを支える基盤になる
- WIKESPEED
- チームはビジネス価値を持つモジュールのオーナーとなる
- モジュールによって並行したスクラムが可能となり、ベロシティを維持・向上させることができた
- ムーアの法則のメリットを製造にも転用(ラインがマルチパス化)
- WIKESPEED
- モジュール化のオペレーター
- デザイン階層より下位のモジュールが進化しうることが重要(下位システムの不確実性に強い)
- 下が可変
- 設計手段
- 分離
- 交換
- 削除
- 追加
- 転用
- 抽出
- デザイン階層より下位のモジュールが進化しうることが重要(下位システムの不確実性に強い)
- モジュール型製品と総合型製品
- ある機能のために複数のモジュールを調整しなければならない製品は、モジュール型製品と呼ばない
- モジュール性が高い＝機能とモジュールが対応付いているか、が一つの尺度になる
- モジュールの設計改善
- 蜜
- とじたもの
- デザインルールに従う
- 疎
- デザインルール自体の改善
- 蜜
- 分割単位としてのドメイン
- DDD
- ドメイン
- 問題や知識の領域
- ドメインモデル
- ドメイン上の概念
- DDD
- ドメインの考え方に従うことでビジネスの変化にソフトウェアが対応できるようにすること
- ドメインがモジュールの分割単位になるかというと、そう簡単な話ではない
- ドメイン
- DDD
- ドメインとBCの関係
- BC：境界づけられたコンテキスト
- 組織が扱う関心ごとはドメインというより境界づけられたコンテキスト
- BCとシステム・チームを合わせる
- ドメイン概念を把握しやすくなる
- チーム間のコミュニケーションがそのままシステム設計につながる
- コンウェイの法則
- 『エンジニアリング組織論への招待』
- 適切な分割とは
- バランスが難しい
- 絶対的な基準はない
- 探索しながら適応するしかないのでは
- バランスが難しい
- モノリスは本当に問題化
- モノリスにも利点がある
- モジュラモノリスという選択肢
- MSA文脈でのモジュラモノリス
- 部分的にモジュラモノリスを採用する
- 関係が強いものは近くに、弱いものは遠くに
- 新たな課題：フロントエンドモノリス
- フロントエンドにもモジュラモノリスの発想が必要
- 明示的なデザインルールと隠されたデザインパラメータ
- 個々の部品がモジュール
まとめ
- 複雑なものは分けて考える
- 重要な設計要素はモジュール性とビジネスの関心ごと
- コンウェイの法則
- 単純な発想では分割の落とし穴にはまりうるから注意
- モジュールもモデリングの一つ。どれくらい遊びを持たせるか
- バッファ、可能性を持たせる
- それをしたからといって長期的な変更に確実に耐えられるかというとそうともいかない
- 程度が難しい。明確な答えが見つからない。
感想
- デブサミと今回のOOCで色んな人の話を聞いたことで、DDDのことを少しずつイメージできるようになってきた。
- モデリングとパターン化があるが、QA的にはまずはモデリングについて学んでいきたい
オブジェクト指向プログラミングの現在・過去・未来
17:00〜 共2-201 ロングセッション
オブジェクト指向プログラミングの歴史を振り返りながら、現在の状況と今後の方向性について考えてみます。
- 黎明期
- GUIとオブジェクト指向ブーム
- UMLとオブジェクト指向モデリング
- アジャイルムーブメントとオブジェクト指向プログラミング
- 関数型プログラミングとオブジェクト指向プログラミング
- ドメイン駆動設計とオブジェクト指向プログラミング
- マイクロサービシズとオブジェクト指向プログラミング
かつては、オブジェクト指向の本質といわれたものが、いまでは、わき役になったり、アンチパターンとされるものもある。
そういう流れの中で、これからのオブジェクト指向プログラミングは、どういう方向に進む可能性があるのか、考えてみましょう。
メモ
はじめに
- 『現場で役立つシステム設計の原則』
- 今日は、この本の背景にあるオブジェクト指向プログラミングの基本的な考え方を説明
オブジェクト指向プログラミングとは何か
- 非常に明確な内容だと思っている
- 「データの抽象化」データを分割
- 「抽象データ型が導くモジュール構造」手続きを分割
- この軸をもとに話す
- 型やモジュールが全面的に出てきていないことがオブジェクト指向がややこしくなっている原因の一つ
- この図が現在過去未来
- オブジェクトの解釈はビット列でしかない
- 型は、「値に対して何が実行できるのか」値に対して実行できる操作のセット＋有効な値の範囲
- モジュールは、プログラミング単位。
- データに対する抽象は、操作
- 型は概念、クラスは実装手段、クラスは実装範囲でモジュールになる
- クラスとモジュールと型は同じものだというのがオブジェクト指向の基本概念
型
- 怖くないです
- プログラミングをしていれば、無意識に使っているものだから、それを意識的に使うようにすれば良い
- オブジェクト指向プログラミングは、型を意識するプログラミング
- 型とは何か
- 具体例
- 変数と型
- 式自体が型を持つ
- 当たり前といえば当たり前
- 値の範囲を制限
- 本質はこっちではない
- 可能な操作を定義
- 型によってできる操作が違う
- 具体例
- 可能な操作の定義→データの抽象化
- データの抽象化とは、値の分類
- 同じ操作ができる値＝同じ種類の値
- 可能な操作で値の種類を定義する
- データ表現ではなく、データ操作を抽出する
- やりたい操作、可能な操作を定義する
- データ抽象で何が嬉しいか
- 具体的なデータ型と、抽象的なデータ型
- どちらが楽か
- リスコフ「型は問題領域を記述する『語彙』を提供する」
- ストラウストラップ「型は計算のアイデアの表現である」
- バートランドメイヤー「型は問題領域の記述とプログラムの構造を直接的にマップする」
- バートランドメイヤー「型はソフトウェア仕様の記述手段である」
- エリックエヴァンス「型で関心ごとを明示的に表現する」
- 得た問題領域の知識を型という手段で記述する。DDD
- 意図の表現の手段が型
- 具体的なデータ型と、抽象的なデータ型
- データ抽象の具体例
- 取り得る値の範囲の制限
- 契約による設計
- 引数の型を制限することで事前条件は決まってくる
- ビジネスルールに基づく計算判断の意図を表現する基本手段
- 計算判断の実装の詳細を隠蔽する基本手段
黎明期
- イノベーターとアーリーアダプターの時代
- FORTRAN
- ビット列を整数型と実数型に分類して扱うようになった
- 値の種類を型で分ける、という考えの原点
- Simula 67
- オブジェクトとクラス
- CLU
- 抽象データ型とカプセル化
- C++、Smalltalk、Eiffel
- 研究と実践
- Java、UML
- オブジェクト指向の転換点
- ブームが混乱を生んだ
- オブジェクト指向の転換点
- FORTRAN
1995-2000 Javaの登場と爆発的な普及
- すごかった
90年代：オブジェクト指向分析設計：混乱の始まり
- 型の定義と発見を見失った
- 従来のモデリングから型を見出そうとしたが上手くいかず、だからこそ混乱した
2004年：Javaの大変身
- ジェネリクス
- 型のない言語でオブジェクト指向プログラミング？
型のない言語でオブジェクト指向プログラミング？
- どうやって抽象データ型プログラミングをするんだ？
- 動的
- 漸進的な型付け
- 「これはこじつけ」
- 型は勉強してほしい
- よくわからないままなんとなくするのではなく、勉強してほしい
収束の兆し
- 実験結果が出始めた
- UML復旧しなかった
- 型がないのつらい
2015年頃
- やっぱり型なんじゃないか？
オブジェクト指向プログラミングの進化
- 参照透過性
- NULLポインター使わないように
- IDEという素敵な相棒
現在の状況とこれからの20年
- 手続き型プログラミングがまだまだ主流
- 予想
- スクリプティング言語の型対応の変化
- IDEの型サポートの進化と普及
- など
感想
- 「〇〇とは」が掌に乗っている感じですごかった
- しっかり古典や一次情報に触れようと思った
- 「意図の表現の手段が型」というのが印象に残った