GLATTS勉強会ブログ

参加者 青木（読み手）、今井、沼田（記）
範囲 pp.164 – 174

7章 テスト

• 7.4 面倒なエンドツーエンドテスト
• 7.5 エンドツーエンドテストの欠点
• 7.6 信頼できない脆弱なテスト
  • 7.6.1 誰がテストを書くか
  • 7.6.2 実行期間
  • 7.6.3 積み上がる大きな山
  • 7.6.4 メタバージョン
    • p.169 l.2
      …デプロイすればいいのでは？（脱字）
• 7.7 ストーリーではなくジャーニーをテストする
• 7.8 救いとなるコンシューマ駆動テスト
  • 7.8.1 Pact
    • p.172 l.6
      Ruby DSLとあるがPact DSLでは？
  • 7.8.2 対話について

参加者 沼田（読み手）、青木、今井（記）
範囲 pp.150-164

6章 デプロイ

• 6.12 デプロイのインタフェース
  • 6.12.1 環境定義
• 6.13 まとめ

7章 テスト

• 7.1 テストの種類
• 7.2 テストスコープ
  • 7.2.1 単体テスト
  • 7.2.2 サービステスト
  • 7.2.3 エンドツーエンドテスト
  • 7.2.4 トレードオフ
    • p.161 7.2.4下から2行目 脱字
      どのよう名前で → どのような名前で
  • 7.2.5 いくつのテストを実施するか
• 7.3 サービステストの実装
  • 7.3.1 モックかスタブか
  • 7.3.2 高度なスタブサービス

参加者 今井（読み手）、沼田、青木（記）
範囲 pp.136-150

6章 デプロイ

• 6.9 サービスからホストへのマッピング
  • 6.9.1 ホストごとに複数のサービス
  • 6.9.2 アプリケーションコンテナ
  • 6.9.3 ホストごとに１つのサービス
  • 6.9.4 PaaS
• 6.10 自動化
• 6.11 物理から仮想へ
  • 6.11.1 従来の仮想化
  • 6.11.2 Vagrant
  • 6.11.3 Linuxコンテナ
  • 6.11.4 Docker

参加者 青木（読み手）、今井、沼田（記）
範囲 pp.126 – 136

6章 デプロイ

• 6.3 ビルドパイプラインと継続的デリバリ
  • 6.3.1 避けられない例外
• 6.4 プラットフォーム固有の成果物
• 6.5 OS成果物
• 6.6 カスタムイメージ
  • 6.6.1 成果物としてのイメージ
  • 6.6.2 イミュータブルサーバ
• 6.7 環境
• 6.8 サービス構成

参加者 沼田（読み手）、青木、今井（記）
範囲 pp.112-126

5章 モノリスの分割

• 5.15 サービス呼び出しを介したデータ取得
• 5.16 データポンプ
  • p.115 図5-14
    上の、顧客サービス、経理、在庫は、データポンプのことか？
    → ↓矢印の中にデータベースとデータポンプがあると見るのでは？
  • 5.16.1 代替手段
• 5.17 イベントデータポンプ
• 5.18 バックアップデータポンプ
• 5.19 リアルタイムを目指す
• 5.20 変更のコスト
• 5.21 根本原因の理解
• 5.22 まとめ

6章 デプロイ

• 6.1 継続的インテグレーションとは
  • 6.1.1 実際にCIを行っているか
• 6.2 継続的インテグレーションのマイクロサービスへのマッピング

参加者 今井（読み手）、沼田（記）
範囲 pp.96 – 111

5章 モノリスの分割

• 5.3 モノリスを分割する理由
  • 5.3.1 変化の速度
  • 5.3.2 チーム構成
  • 5.3.3 セキュリティ
  • 5.3.4 技術
• 5.4 入り組んだ依存関係
• 5.5 データベース
• 5.6 問題の対処
• 5.7 例：外部キー関係の削除
• 5.8 例：共有静的データ
  • 第2の選択肢だと、DBを直接見る場合は国コードの対応がわからず、コードに含まれる国コードの知識が必要になる。
• 5.9 例：共有データ
• 5.10 例：共有テーブル
• 5.11 データベースリファクタリング
  • 5.11.1 段階的な分割
• 5.12 トランザクション境界
  • 5.12.1 後でリトライ
  • 5.12.2 操作全体の中止
  • 5.12.3 分散トランザクション
    • p.108 l.8
      一貫性を維持を→一貫性の維持を、のほうが自然では。
  • 5.12.4 何をすべきか
• 5.13 レポート
  • p.110 l.1
    他のユーザと同様にユーザで、私たちは…と読点を入れたほうが意味がとりやすいのでは。
• 5.14 レポートデータベース

参加者 沼田（読み手）、青木、今井（記）
範囲 pp.82-96

4章 統合

• 4.14 ユーザインタフェース
  • 4.14.4 UI部品合成
  • 4.14.5 フロントエンド向けのバックエンド(BFF)
  • 4.14.6 ハイブリッド手法
• 4.15 サードパーティソフトウェアとの統合
  • 4.15.1 制御の欠如
  • 4.15.2 カスタマイズ
  • 4.15.3 統合スパゲティ
  • 4.15.4 思い通りにする
    • 4.15.4.1 例：サービスとしてのCMS
    • 4.15.4.2 例：多目的CRMシステム
  • 4.15.5 ストラングラー（絞め殺し）パターン
• 4.16 まとめ

5章 モノリスの分割

• 5.1 すべては接合部次第
• 5.2 MusicCorpの分解
  • p.95 二段落目の二行目
    「対話するのとグループと」の部分が、文章上つながりがわからない。
    → 原書では、

    in the same way the real-life organizational groups in our domain interact.

    なので、「組織のグループが対話するのと同様に」だろう。

• 5.3 モノリスを分割する理由