ソフトウェアアーキテクチャに関わる記事へのリンク

• 根源にある考え方
  • 一度に考慮すべき範囲は小さいほど上手くいく
  • KISS原則
• その考え方に基づくアプリケーションの構築方針
  • 小さく区切られたブラックボックスを組み合わせて大きいシステムを造る
  • divide-and-conquer/分割統治
  • link
• 良い分割の方針
  • 何に基づいて分割するか
    • 関心ベース: 関心の分離 −利点とそれを促すアーキテクチャ−
      • (コア)ドメインモデルが中心的関心
        • クリーンアーキテクチャ
        • ヘキサゴナルアーキテクチャ
        • オニオンアーキテクチャ
• 分離面 (インターフェース) の形式 (∝質)
• 分割された要素間の関係性
  • 依存: プログラミングの依存とうまくやっていく
    • 中心的関心領域を他に依存させない
      • DDD? (ドメインのモデルを他に依存させない)
    • 技法
      • DIP
      • DI

移譲と関数と高階関数、依存性の注入

分離面 (=インターフェース) の質

モノリスをぶった切ればひとまずインターフェースは生まれる
これを変更（改良・修正）する際のコストが1つの指標。
他には関心の分離を促進してくれるか崩しやすいか

変更に対するコスト
変更不可、はありえない。実務上変更困難、はよくある
良いインターフェースは内部変更コストを小さくしてくれて、動的なコードを可能にする

インターフェースの種類: 呼ぶ & 公開して呼ばれる (プライマリー & セカンダリーアダプター in ヘキサゴナルアーキテクチャ)
変更しづらい形式とは
変更がインターフェースそのものの変更を起こしてしまうパターン.
インターフェースが内部実装と強く関連しており、内部実装の変更や差し替えに大規模なコード変更を必要とする場合.

目的とインターフェースが不一致（不必要に広い、必要以上に絞られている）と起きやすい
e.g. "保存"が目的なのに、DynamoDBに対するpostが目的となっているインターフェース

インターフェース形式はその設計にownershipを持つ関心事から強く影響を受ける

外部サービスが当然APIを持っているので、そこを出発点として抽象化していきがち

良いインターフェースを書くコツ

私のためのインタフェース、は私が
依存したいインタフェースは、依存する人がよくわかってる
インタフェース設定の手間をかける価値があるドメインなら、依存するインタフェースを自分でownership取って設計する

1. 自分で決めるから閉じた開発が可能
2. 良質なインターフェースが実現

「抽象への依存」そのものが大切なのか？

Q: 低レベル具象クラスの構造をインターフェースとして切り離し、それをDIでドメインモデルに渡したらクリーンアーキテクチャなのか？
A: No。使いづらいインターフェースだったらさっぱり目的 (実質的依存の軽減からくる柔軟性とテスタビリティ) を達成してくれない。インターフェースへの依存そのものが重要なわけではない。ドメインモデル中心/主導のインターフェース設計が肝。

Q: 神が設計した、最高の一般化がなされた具象クラスがあったとして、これに直接依存したコードを書くことに問題はあるか？
A: No. 具象クラス内部の実装変更が影響しないように一般化済みなので、高い柔軟性やテスタビリティは確保されている。

これらのことから、「良い分離面」設計が肝心であることがわかる。
「抽象への依存」は良い設計を実現する手法だった？

アーキテクチャフレームワークがもつ役割

理想と乖離しやすい部分を解決
内向き依存のみにする、と言う指針は、コアドメインに対しinterfaceのownershipを強制する効果がある

移譲と関数と高階関数、依存性の注入

委譲 (delegation)

委譲 - Wikipedia

ufcpp.net

関数ポインタに似てるけど、methodが所属してるインスタンスの状態もくっついてくるから、その辺は違う
連載：C#入門 第17回 処理を委譲するdelegate（5/5） - ＠IT
eno0514.hatenadiary.jp

型だけ決めて、委譲する。 = interface実装する実体を後で入れる

用語整理

• 移譲
• 依存性の注入: 設計パターンの一種
• 関数ポインタ
  • ラムダ式
• 制御の反転

根底にある思想・パラダイムは何か

-> interface決めれば、callerとcalleeを分離できる。なのでは？
callerはcalleeを使う/呼ぶので、使い方(I/Oなど)は絶対に知らないといけない
でもより疎結合にしようと努力することはできる
関心の分離が根底か

DIは
「caller内でcalleeをインスタンス化する」
密結合を、
「インスタンス化済みのcalleeを注入する」
疎結合に変える設計パターン

制御の反転

bliki-ja.github.io
制御 == main関数 が誰か、という話.

ライブラリとフレームワーク、がわかりやすい
ライブラリはcallee, つまりmainから呼ばれる側
フレームワークはcaller, つまりmain関数そのもの、呼ぶ側.

callbackはまんまcallee

www.slideshare.net

caller, callee

呼ぶか、自身を登録するか

やはり設計パターンか？

関数ポインタ使わんでもええで、な話
developer.wonderpla.net

依存性の注入

呼び出し側 (caller) が呼び出され側 (callee) を呼ぶ際、
caller内でcalleeを生成したりせずにconstuctorなどで外部から注入する設計パターン.
callerはcalleeの機能を使っている、つまりcallerはcalleeに依存性している。
この依存物を外から注入して使うパターンがDI.

一度に考慮すべき範囲は小さいほど上手くいく

small is beautiful (UNIX)
考慮範囲は小さいほうが脳みそ楽でうれしい (怠惰)

関心の分離

線引き

マイクロサービスアーキテクチャ

正しくない解釈が発生しうる局面

考慮すべき範囲なのもポイント。
広い視野で新しい発想をする、みたいな場面で考慮範囲を最初から無理やり小さくしてたら色々見落とす可能性が高い.

不満の伝言ゲーム

不満: 具体的現象に対する不満 & 曖昧な心理状態に対する不満

不満の伝言ゲーム

伝言ゲームからわかるように、情報は劣化しながら伝達する。 不満も、具体的な原因を伴った不満が、他者によって観測をされ、それがさらに観測されるうちに、具体性を失っていく。 不満という感情そのものは具体性がもともとないため、これは減弱されず、むしろ原因が失われることによって不満のみが強調されて伝達されていく。 結果として、謎のぼんやりとした不満が場を支配することになる。

情報は劣化しやすく、感情は劣化しづらい

伝言ゲームは不満ばかりを伝達し、場を根拠なきぼんやりとした不満で占拠する。

ごく少数の具体的な不満を各自が別々に知っていることで、ぼんやりとした不満全体が具体的な実態であるかのように錯覚する。「聞いてみたらなんでそんな小さいことに滅茶苦茶イライラしてるの？」はこれの可能性 ストレス・不満・いらいら

解決策

具体化する。失われた情報を具体化して補完する。
そもそも伝言ゲーム化を防ぐ。

様々なデリバティブ(金融派生商品)たちと原資産を結びつける力

デリバティブは、原資産から派生した金融商品である。
原資産の値動きを反映する (と期待して合成された) 商品である。
では、その原資産値動きとの相関はいかにして作られるのか。
理論価格のようなものはあるのか。

• 先物/futures: 原受け/渡し、あるいは原資産市場から計算されたSQ
• オプション/options:
• 差金決済/CFD: ただの信用？

清算があれば、理論価格と実取引価格が強制的にわかりやすく一致する

マーケットメイカーは、対象指数の先物市場の価格等を参考にしながら、需給・相場・建玉等の状況を勘案して、「くりっく株３６５」の価格を提示しています。そのため「くりっく株３６５」の価格は、現物の株価指数そのものではなく、また買い価格と売り価格のスプレッド幅も一定ではありません
よくある質問｜くりっく株３６５公式ホームページ

www.orsj.or.jp

www.jip.co.jp

Instance Normalization

画像スタイル変換の論文にて考案
コントラストはStyle latentに含まれるべきなので、contentは定コントラストであるべき
なので1枚の画像内コントラストを正規化する方法を考えた
結果としてBNを置き換えるInstance Normalizationを着想した

浅い層ではコントラストだが、深い層では何をしているのか
潜在表現の内部正規化とは

Instance Normalization: The missing ingredient for fast stylization

Neural ODE

Neural ODE: 入力が、連続な隠れ層を滑らかに変化しながら出力になると考え、各点の勾配を（微分値）をニューラルネットワークでモデル化し、ODE solverによる積分で入力を出力へ変換するモデル
すなわち、dx/dt = NeuralNetwork(x, t; θ)、x(t_start) = inputという常微分方程式の初期値問題をsolverによる数値計算で解くのがNeural ODE

ある時刻（深さ）での隠れ層のダイナミクスを出力する f(h(t), t, θ) を、ニューラルネットワークでモデル化し、これをODENetと呼ぶ
ref

1. supervised learning

we evaluated the hidden state dynamics and their derivatives on the GPU using Tensorflow, which were then called from the Fortran ODE solvers, which were called from Python autograd code.

Python autograd:  
    Fortran ODE solvers:
        ODENet on GPU using TensorFlow  

ResBlock: BN + ReLU + weight + BN + ReLU + weight

1-Layer MLP (300 hidden units)
ResNet: downsampling 2 + Res 6
RK-Net: BP on Runge-Kutta integartor
ODE-Net