OOC 2020
websites
table:ホール対応表
A 2-201 \#ooc_a
B 2-101 \#ooc_b
C 2-102 \#ooc_c
D 1-304 \#ooc_d
E 1-301 \#ooc_e
以下ノート
keynote: Object-Oriented Diversity
どのOOPL?
ADT vs message-passing
diversity
多様性、多態性、多相性
interface
OOP as a Interface
why polymorphism
e.g. Model, Entity, Domain, HTTP
「恐れずに使ってほしい」
マサカリではない
言いたいだけ
文脈を確認しよう
結局ソフトウェアエンジニアリング・オブジェクト指向・モデリングでしょ
会社紹介、豆蔵
「1粒の知性がソフトウェアエンジニアリングを変える」
型$ \congモジュール$ \cong概念
programming $ \cong software design & engineering $ \cong domain
ここでバトンタッチ
上は変わらないパターンでは
OOPとも呼ばないかもwint.icon
why engineering
ソフトウェアの構造、つまり設計では？
why domain
安定性
e.g. MBSE, SysML, OOSEM
つまり中心にOOP
OO分析
契約による設計事始め
what?
契約
顧客モジュールと供給者モジュール
その間の依存
定義 = 契約、これが必要
権利と義務
適切なコミュニケーション
methodology
事前条件
ルーチン本体
事後条件
メリット
防御的コード不要
シンプル
責任の所在が明らか
不変条件
実行時エラーは消えない
例外も然り
例外は契約の放棄
validation は外部との境界
assert は内部
根本的に違う
assert は本番で消せるべき
表明は動くドキュメント
spec とも言えるwint.icon
対応状況
JSwint.icon
はじめる
事前条件を書く
型でかけるに越したことはない
表明違反を通知
assert to alert!
バグ修正
結構簡単
表明違反は例外なくバグ
つまり例外は例外なく例外wint.icon
Q&A
効果とチーム導入
最初から。デバッグで時間浪費しなくなった
地道に啓蒙、率先垂範
ChatWork
スライド非公開
モデル
理想と現状
トップダウン
アクター図
全部署がコンテキストに関わる
明示できて良かった
個人SPOFが分かった
実践
早く失敗
トップダウンでなくボトムアップ
成果まで遠い
データ構造から分析
モジュール依存性グラフ
Javaに書き起こす
JIGで可視化
クラス
単語が分からない
用語定義
階層が見えてきた
更にパッケージ化
実践
開発文化
技術力評価会
査定
相互評価
率直フィードバック
モチベに
Q&A
誰に誰を？
第三者
別部署による評価
なくなったら困ること
第三者への説明の機会喪失
タコツボの再発
自分の価値が見えなくなりそう
READYFOR
日本初クラウドファンディング
ドメイン
プロジェクト
fat model project.rb 3.7k LOC...
SoC
context
資産の一種
やはり不良資産
by Dan Kogai
ソフトウェア資産の一部
↔技術的純資産
対策、リファクタリング
不良資産の転換wint.icon
注意
正統性はないと主張
間違ってた
オブジェクト指向じゃなくてプロセス指向
OOPSLA 1997
「間と言いたかった」
ダイナミズムとフリースケール
メッセージ
構造よりも過程
決定よりも遅延
アジャイル
RESTful
20年経った
コンポーネント分割基準
隣と2分話すグループワーク
発表
自分。顧客のドメイン用語と技術によるレイヤー分割
お隣。用語にできると良い
アプリ屋。拡張されそうなところを勘で分割
QA。ユースケースベース、コンポーネント単位、品質特性、各側面別
よくみる負債
やりたい（今と将来）からの乖離
プランB（代替）の不足
技術変化への追従不能
対処
リファクタリング
大規模に向かない
リストラクチャリングの体系がない
スモールリリース
メリット捨ててる
DDD
システム全体への体系がない
クラウドアーキテクチャ
現在への最適化
未来は不明
why?
1. アイディア、仮説、要件
アーキテクチャ
アプリ
リリース
監視
可視化
1, 2 のカバーが少なく、ギャップが大きい
決めすぎるから勘に頼る
再掲
アラン・ケイの精神
仮説
1→2の間に数理的システム設計
アジャイル
変化する機能要件に依存してはいけない
技術もユースケースにも
つまり
構造を決定しない設計
質を決定する
絶対に変化しない何か
→美しさ
良い建築
普遍性が高い
→良い設計につながる？
book: nature order?
良い設計とは
手戻りが少ない
瑣末な変更で済む
保守性に等しい
経済的合理性wint.icon
数理的アーキテクチャ
定量的とも言える
間違いにくくなる
methodology
ソフトウェア用語を使わない
論理的なシステムができる
現実とのギャップ分析ができる
15特性
実例で使う順番を見る
最初に 10 段階的変容
step 1 の軸
情報の合成度 / 情報間の地理的距離
質・責務・関係を見出していく
実務では
3軸
パターンランゲージ
価値
普遍性
数理的
セミ・ラティス
用語
メッセージ
センター
間
生きながらえることが大切
強い生命
vivid, life, quality
間ではあるけど、ハコやサブ・システムではない
1対1とは限らないwint.icon
建築のパターン: ドア
ソフトウェアではGW
Ma-Oriented
間が本質
オブジェクトやメッセージは2次的
インターフェイスの決定を遅延
つまり構造の決定の遅延
システムレベルの遅延が大事では？
探索中
プロセス例
グルーピング
インサイト
システム、アプリ構造の発見
課題
システム構成図にできる？
難しい
まだα版
建築
重力があるから常識に従う
ソフトウェア
重力のような法則が見いだせてない
Q&A
2軸 or 3軸？
勘で決めてる
3つではCAD
数理的は違和感。概念的・論理的でいいのでは？
幾何学ベース。まだ課題
建築の概念を輸入できるのか？あくまで参考？ e.g. roughness
roughness 使いやすい
拡張性の観点
pluggablewint.icon
void 使いにくい
CSの法則使えるか
どれくらい時間かかる？
1~2日くらい
2週間で 1st draft
感想
マクロレベルの数理的モデリング
アジャイル時代のモデリング
スライド非公開
from Aster
Agile & Design
モデリングからアジャイルへ軸足を変えてきた
Agileはドキュメントを重視しない
技術的負債をコントロールしたい
Agile の概念図
user requirements → ？ → moving software
where is the design?
コードに散らばった設計意図を復元できるか
ドキュメント
grady booch of the 4
"While code is the truth, it is not the whole truth."
サグラダファミリア
成長し続けるが、一貫した美がある
コアになにがある？力はなに？
vs 日本の建て増し旅館
また建築wint.icon
こうありたい
障害だった
アーキテクト（マトリックス）は現実的か？
No
NDUF ← ENUF (here) → BDUF 『Design it!』
architecture sweetspot
the balanced point
per project, per context
5 parameters
scale of number of people
時間コストを償却できるwint.icon
againt bureaucracy by Scott Abler
modeling is important
why model
good for human
e.g. cake wrecks
"user story mapping" にもあったwint.icon
盲人模象
象の像
what is the simplest set of models?
in a design process
残すモデルと捨てるモデル
the keeps
the temps
クラス図
casual modeling
記念写真くらい
the 3 keeps
architecture
a whole big picture
構造的な表現
大域的な表現
agile は収穫するとは言うけど…
POSAとかのパターンは使える
パッケージ図
DIP違反をlintしたい…
domain model
DDD
visual oriented
key use cases
who, how good
goal = use case
典型的なユースケース図
temps は keeps の上に ad-hoc に書けばいい
conquers and divedes -- Kent Beck
implement first
model to conversation
other keeps
Architecture Decision Records
by Design it!
testing strategy
other modelings
impact mapping
C4 Model
by simobrown
aginst costy UML
software context > container > component > code
Notation の思想が良い
凡例によって自己説明的にする
アイコンは補助
タイトルはクラスとインスタンス
"abstractions first, notation second"
ユビキタス言語が最も大事
まとめ
設計は消えない
残るプロセスの大事さ
世代継承のため
「モジュールとしてのマイクロサービス」と 「分割単位としてのドメイン」について考える
テーマ
境界定義の難しさ
マイクロサービスの文脈
部品分割=モジュール化
50年の歴史
工業でも
モジュールとドメインの関係と課題
service
ビジネスの遂行能力単位
可能になった前提
DevOps, cloud, full automation
MSA以前の問題
内部の境界が厳密でない
芋づる
→疎結合
monolith でもできるのでは？
分業の仕方
水平に切ってた
自治権がない
自己組織化できない
変化
分散システムになってしまった
トランザクションが困難
by Martine Faulor
コンポーネント$ \simeqモジュール
モジュール
入れ子にできる
フラクタル
複雑性の制御
疎密
当たり前では？
コア概念
境界がある
=隠蔽されてる
インターフェイスには事前合意が必要
明示的なデザインルール
アーキテクチャ
インターフェイス
標準
静的解析
契約プログラミング
型
隠されたデザインパラメータ
内部は勝手に変更できる
あとに遅延できる
でないと、アジリティーとヴェロシティを維持できない
事例
IBM 360; PC AT
デザインルール→fail fast
WIKESPEED
scram; hardware agile on car
iteration: 8 years vs 1 week
歴史: モジュール化（つまり標準化）ですり合わせが不要になるwint.icon
デザイン階層
モジュール化のオペレーター
wint.icon？
機能との対応？
機能に依る
モジュール型↔統合型（すり合わせ型）
module POs' meta scram
チームとの対応
1 module ↔ 1 team
失敗した分割よりは1モジュール（モノリスwint.icon）がマシ
DDD
組織が扱うのはドメインというよりBC (bounded context) では？
BC = 業務単位
BC とシステム・チームとを対応
課題
システム分割が難しい
対応↑複雑度↑保守性↓
modular monolith
by Shopify
チーム規模に依っては難しい
monolith に戻すのは難しい
point of no return の自覚
漸進的にやるしかない
micro frontend
modular monolith in app
まとめ
複雑性には分割で対処
組織のコミュニケーションを阻害しない
分散システムそのものの困難
Q&A
分割単位は探索的にするしかない。分割し直しが難しい
予測は難しいが、最適なコストでモデリングしておきたい
遊びの程度を調整
YAGNI vs cowboy
感想
MSAは microservice premium を参照したい (martin faulor) 異なるモデリングパラダイムから見るオブジェクトモデル
by すえなみ
焼肉をタカられてる人
人物
アラン・ケイ
ストラウストラップ
バートランド・メイヤー
エドガー・F・コッド
クリス・デイト
ピーター・チェン
更に
ジェームス・コプリエン
リッチ・ヒッキー
agenda
2 OOP
modeling
non OOP
multi paradigm
model
computation
data
2 OOP
class based
message based
アラン・ケイ
動的、遅延結合
歴史
構造化 & モジュラー
データ抽象
インターフェイス
ユーザー定義
クラス
クラスの系譜
データ抽象
もっと古くはCからある
抽象データ型
by リスコフ
クラスをモジュールとして使う
つまり
関係を定義する
これでシステムを表現する
モデル→実装
決定の遅延とも言える
message based
処理系そのもの
自分で作れる
personal computing
支える技術
massage は receiver が動的に判断する
受け取ってから、その場で処理を書いても良い
実行後遅延
cf. Ruby method_missing
オブジェクトの独立性
cf. Erlang
重要度不等式
メッセージ >= オブジェクト >> クラス
クラス・メソッドは実行パフォーマンスのためだけにある2次的な存在
まとめ
違うよ
クラスは型システム援用
早期結合
メッセージの方はインターフェイスすら後付
限りない拡張性
メッセージから学ぶ
コンセプトはアーキテクチャに活かせる
インターネットなどの分散システム
e.g.
Pub/Sub
Queuing
Async
Logging
受け取る側が解釈を頑張る発想
意思決定の遅延
遅延結合の意義
class でも実装の遅延
OOP自体が遅延の手法
実装はどうする
別のパラダイム
マルチパラダイム・モデリング
モデルとは、良さとは
抽象
手続きはモデル？
データ型にとっては捨てられたもの
hardware にとってはモデル
→別パラダイムへの委譲
良いモデリング
決定を早くしたいものと遅延したいものを分けられる
モデル2種
計算モデル
チューリングマシン
手続き型
cf. オートマトン
函数型
論理型
e.g. Prolog
データモデル
計算への最適化
広義の計算モデル
アルゴリズムとセット
e.g. SQL & Prolog
ER Model $ \neq Relational Model
ERM 概念モデリングのための手法
演算はない
RM は関係演算
ER Model
→ RM
→ Network Model
graph db?
→ Entity Set Model
transition by mapping
cf. EAV (SQL anti-pattern)
ERMはあくまでview
Q&A
Datomic SQL interfce?
ない。JSONっぽいクエリ
Closing