Java読書会BOF「現場で役立つシステム設計の原則」を読む会第4回¶

開催概要¶
日時	2018年11月24日 10:00 - 17:00
場所	川崎市教育文化会館第3会議室
出席者(敬称略)	岩室、遠藤、小棚木、平山、井上、常念、吉本、高橋(徹)

本日は、p.225 から読書開始です。

第8章アプリケーション間の連携¶

アプリケーションとアプリケーションをつなぐ¶

ほかのアプリケーションとの連携がアプリケーションの価値を高める¶

アプリケーションを連携する4つのやり方¶

4つの方式のうちWeb APIだけ粒度が細かい具体的な手段となっている。
メッセージングは、MOM(Messaging Oriented Middleware)や MQ(Messaging Queue)としても知られている。
メッセージングは、プログラムからみると、Publish/Subscribeな通信を扱える。
組込み(IoT)用のメッセージングにMQTTがある。

Web APIのしくみを理解する¶

HTTP通信を使ったアプリケーション間の連携の4つの約束事¶

要求の対象を指定する¶

要求の種類を指定する¶

パラメータをURIに指定する場合、上限があるので要注意。日本語はエンコードされると1文字が9バイト(%3e%2a%fa とか？)になる。HTTPの仕様には上限がないが、ブラウザやサーバーで実装依存の上限がある。
- 2000文字を上限とするのが推奨らしい
- 上限を越えたときは、ステータス414が"Request-URI Too Long"
GETにボディは付けられない
POSTとPUTの説明は、RFC 7231 に近いものがある。
HTMLのformでは、GETとPOSTしか扱えないが、裏技あるらしい
- hidden属性に_methodを追加
「更新の依頼もPOSTを使う」で、URIにupdateと動詞を指定するのはREST原理的には相応しくない。
現実的にはRESTにしきれずに、URIに動詞を含むRPC的な設計ことがある。
削除依頼をDELETEメソッドからPOSTメソッド(URIにdeletionsを追加して)にすることで、なぜアプリケーション間の依存関係が小さくなるか分からない。

良いWeb APIとは何か¶

使いにくいWeb API 〜大は小を兼ねるのか？¶

アプリケーションを組み立てるための部品を提供する¶

小さいWeb API部品を多数組み合わせるということは、通信コストが高くなる問題があるが、この本では言及されていない

発展性に富んだAPI開発のやり方¶

単純なことをかんたんにできるAPIの提供から始める¶

動かしながら設計を発展させていく¶

基本設計段階でWeb APIを作って動かすのは難しいのでは？
APIの変更管理(構成管理)をしないとカオスとなる

APIを利用する側とAPIを提供する側の共同作業の環境を整える¶

Swaggerは、YAMLベースでAPI仕様を定義し、ドキュメント、各言語へのバインディング(ソース)が生成される。CORBAのIDLのような位置付け。この本ではSwagger UIを紹介しているので、この意義が伝わってこない。
APIの調整(構成管理)にもSwagger UI使えるね(大変だけど)
Swagger動かす環境はプロキシーが介在する等があると厄介
チャットサービスは、メールより投稿の敷居が低い、フィードバックがやりやすい(フェースマークやイイネ)

中核となるAPIのセットを設計する¶

「登録と参照は別のAPIにする」は、「コマンド・クエリ分離」の設計原則に相当するようだ。(コマンド・クエリ分離の出所は、メイヤーのオブジェクト指向入門にたどりついた)
登録と参照を分けることでHTTP通信が2回走るのは気になる
リソースIDだけ返すのではなく、GETのURLを返すHATEOASという概念がある

Web APIのバージョン管理¶

APIを複合したサービスの提供¶

ドメインオブジェクトとWeb API¶

データ形式とドメインオブジェクトを変換する際に起こる不一致¶

導出結果か生データか¶

ISO 8601の日時形式をパーズできるライブラリは実は多くない。ISO 8601に対応していないライブラリにISO 8601形式を食わせておかしいと著者は言っている？
- Javaも、Date and Time APIが導入されるまではISO 8601形式のパーズはできなかった
著者は日時のタイムゾーンはフォーマットに含めずにAPIの決め事とすることを推奨している。しかし、これは誤解の元でありバグの温床となるので、ISO 8601形式とするのが安全性が高いと思う。
日付と時刻を分けるのはよい考え方。でないと、クリスマスがタイムゾーンによって12月24日になってしまったりする。

複雑な連携に取り組む¶

共通部分と個別対応部分を明確にする¶

APIを進化させる¶

小さなアプリケーションに分けて組み合わせる¶

マイクロサービスに対する著者の意見は同意

複雑なデータの交換¶

XMLはツールセットの準備が大変なので賛同はできかねる
XML Schemaで構造決めれるからよいと思う

非同期メッセージングを使ったアプリケーション間連携¶

第9章オブジェクト指向の開発プロセス¶

開発の進め方はオブジェクト指向で変わったのか¶

開発の基本はV字モデル¶

短期間で開発し修正と拡張を繰り返すことが重要になった¶

オブジェクト指向の開発はうまくいっているのか¶

どちらのやり方でも変更がやっかいなソフトウェアが生まれやすい¶

ドメインモデルを中心にしたソフトウェア開発の進め方¶

業務ロジックに焦点を当てて開発を進める¶

ソースコードを第一級のドキュメントとして活用する¶

多くのドキュメントは不要になる¶

重要になる活動¶

更新すべきドキュメント¶

全体を俯瞰するドキュメントを作成して共有する¶

技術方式のドキュメントもソースコードで表現する¶

技術方式とは何を指すのか？
- 使用しているフレームワーク、言語、ミドルウェアのことかな？

非機能要件はテストコードで表現する¶

分析と設計が一体になった開発のやり方をマネジメントする¶

見積もりと契約¶

進捗の判断¶

品質保証¶

要員と体制¶

第10章オブジェクト指向設計の学び方と教え方¶

オブジェクト指向を学ぶハードル¶

オブジェクト指向の説明は意味が不明¶

なぜオブジェクト指向で設計すると良いのかがわからない¶

オブジェクト指向をどうやって学ぶか¶

既存のコードを改善しながらオブジェクト指向設計を学ぶ¶

実際のコードで設計の違いを知る¶

重複したコード¶

長いメソッド¶

巨大なクラス¶

リファクタリングは部分的に少しずつ¶

組み立てやすい部品に改善する¶

設計は少しずつ改良を続ける¶

オブジェクト指向らしい設計を体で覚える¶

古い習慣から抜け出すためのちょっと過激なコーディング規則¶

次回¶

日時： 12月22日(土) 10:00-17:00
場所：川崎産業振興会館第1研修室
新しい課題図書を読み始めます。