Monthly Archives: 1月 2017

「マイクロサービスアーキテクチャ」第14回(1/31)

Posted on by 0 comment

参加者 青木(読み手)、今井、沼田(記)
範囲 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 対話について

「マイクロサービスアーキテクチャ」第13回(1/27)

Posted on by 0 comment

参加者 沼田(読み手)、青木、今井(記)
範囲 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 高度なスタブサービス

「マイクロサービスアーキテクチャ」第12回(1/24)

Posted on by 0 comment

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

6章 デプロイ

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

「マイクロサービスアーキテクチャ」第11回(1/20)

Posted on by 0 comment

参加者 青木(読み手)、今井、沼田(記)
範囲 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 サービス構成

「マイクロサービスアーキテクチャ」第10回(1/17)

Posted on by 0 comment

参加者 沼田(読み手)、青木、今井(記)
範囲 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 継続的インテグレーションのマイクロサービスへのマッピング

「マイクロサービスアーキテクチャ」第9回(1/13)

Posted on by 0 comment

参加者 今井(読み手)、沼田(記)
範囲 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 レポートデータベース

「マイクロサービスアーキテクチャ」第8回(1/10)

Posted on by 0 comment

参加者 沼田(読み手)、青木、今井(記)
範囲 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 モノリスを分割する理由