「Design It! プログラマーのためのアーキテクティング入門」感想

Design It! プログラマーのためのアーキテクティング入門

https://www.oreilly.co.jp/books/9784873118956/
Amazon


全体レビュー

設計を行うためにどのようなことを考えるべきかを書いた本。最初で全体的な流れを説明し、後半で個別の手法について網羅的に述べている。

俯瞰した視点と、設計のための道具を知ることができると思う、コンパクトに全体像をつかめる本はあまり無く、その点でも良い本。

詳しい道具の使い方はこの本の範疇外ではあるが道筋がわかるというのが助かる。

各章紹介

目次は上のリンク先にある。内容的には以下のようになる。

  • 1 ソフトウェアアーキテクトとは
    • 「望まれる品質特性やその他の特性を促進するためにソフトウェアをどう構築するかということに対する、重要な設計判断が集まったもの」(p.8)
    • ビジネス、技術、ユーザー、それぞれに責任を持つ
    • エンジニアリングの立場から問題を定義し、システムを構築する
    • 品質特性のトレードオフの決定、技術的負債の管理、チームスキルの向上
    • プログラマーからソフトウェアアーキテクトになるために、プロダクトポートフォリオを作成してみよう
      • ビジネス目標、ステークホルダーの書き出し
      • どんな技術に取り組んだか
      • 最大のリスクと克服方法
      • やり直すならどこか
    • ソフトウェアアーキテクトによりもたらすこと
      • 大きい問題を小さく管理しやすく
      • 人々の協働の仕方を示す
      • 複雑な問題に対するための語彙の提供
      • 機能以外にも目を向ける
      • コストのかかる間違いを避ける
      • 変化に柔軟に対応する
  • 2 デザイン思考
    • 問題をどう理解し取り組んでいくかについて
  • 3 デザイン戦略
    • 事前の設計が全体のコストを下げるのにいかに重要かについて
  • 4 ステークホルダー
    • 誰と会話すべきか発見し、ビジネス目標を定義することについて
  • 5 要件の掘り下げ
    • 技術的要件とビジネス要件について、分類し定義する
  • 6 アーキテクチャを選ぶ
    • あー来てきちゃの全体構造を決定するために、要素とその役割を探求する
    • 選択肢に対して品質特性を考え評価する
    • 設計判断のタイミングについて
  • 7 設計パターン紹介
    • レイヤー、パイプ、pubsubなどのパターン紹介
    • なお何も考えられていない状態は「巨大な泥団子パターン」と呼ばれる
  • 8 モデル
    • 概念や規則のモデル化
    • 矛盾を調整し、良い名前をつけ、ドメインを抽出する
  • 9 話の進め方
    • アーキテクチャ設計に適切な人に参加してもらうことで、設計判断に対する合意形成をし、チームコミュニケーションを改善する
    • ここでの話の進め方について
  • 10 図による可視化
    • 図にした上で、どのような改善をするか
    • パターンを際立たせる
  • 11 アーキテクチャの記述方法
    • 必要な共有対象に対して必要なドキュメントを作る、管理する
    • 選ばなかった内容も記述する
  • 12 アーキテクチャの評価
    • 評価方法について
    • 良い質問をする、評価レビュー方法、課題発
    • 形式的な手続きのいらない方法からはじめる
  • 13 チームの強化
    • 設計権限の移譲の意味
    • 設計権限の移譲までの道のりとその後
  • 14 問題発見手法紹介
    • 問題を発見し理解するための各種手法について紹介
  • 15 問題解決手法紹介
    • 解決策を見つけたり、他の選択肢を選べるようにする
  • 16 設計理解のための手法紹介
    • コンテキスト図やシーケンス図を含む、可視化と理解の手法について
  • 17 設計の問題点解決のための手法紹介
    • 評価では、設計を批評的に分析して、ニーズを満たしているかを判断する
    • 評価は継続的な活動で、最後にだけやるものではない
    • 設計の評価手法について

Cookpad Tech Kitchen #22 決済基盤の最新事情 に行ってきました

Cookpad Tech Kitchen #22 決済基盤の最新事情 - connpassに参加してきました。以下は内容のメモですが、それぞれスライドを公開していらっしゃっているので、そちら見た方がいいです。

概要から入り考えていることと目指していることを紹介しつつ最新情報を紹介したりととても整理された上で良い内容でした。



「クックパッドにおける決済基盤の歴史とこれから」
20191127_financier.pdf - Speaker Deck

決済基盤とユーザー基板の部長
エンジニア募集しています
今3人

コンウェイ システム設計は組織構造を反映させたものになる
逆コンウェイ? 望ましい組織構造を促進法させるためにチームと組織構造を進化させる

経理、カスタマーサポート、複数のサービス、複数サイトの決済ゲートウエイ
基板がないと実装がばらばらに、経理も都度対応、契約書も複数

経理、カスタマーサポートは決済基盤とやりとり、サービスは決済基盤とやりとり
社内のセンモンチシキのハブとなる

フィナンシェという共通課金基盤を作った Financier
クックパッド本体から分離して作った 2012
様々な課金方法の差違を吸収
定期課金、その履歴
整合性
管理画面からキャンセルできるように
知見の集約

やらないこと
商品管理
個々のサービスに依存すること


歴史
2013-2017 ウェブしかなかった、直接アクセスポイントもある
2018- アプリ、アプリ内課金、アプリからデータ移動
2018- アプリ内課金、サブスクリプションとそのユーザー完了、課金のappleアカウントとユーザーは別なので統一で扱うAPIとSDKを作った

これから
ユーザー完了基盤との連携強化
c2c


「アプリ内課金の最新事情 クライアントサイド編」
アプリ内課金の最新事情 クライアントサイド編 / In-app Purchase in Cookpad 2019 - Speaker Deck

O'Reilly Japan - Design It!がいい本

定期課金機能の新機能を取り入れつつある
Cuisineというシステム
クックパッドは基本的に定期購入で、運用実績はある
iOS Promoting IAP, Promotional Offers
Android
アップグレード、ダウングレードは意図的に使っていない

API、実装ガイドライン、SDK提供
意図的に依存ライブラリを減らしている
課金まわりには固有ロジックが入る可能性が高いので自作
ここでいう実装ガイドラインとは、課金に対して各アプリで自前実装する際のガイドライン

共通化はやればできる
機能の話を受け手から動くと遅い
新機能の取り込みつつ、なるべき汎用的な概念に落とし込む


「アプリ内定期購入における状態管理と”通知”の活用 」
アプリ内定期購入における状態管理と”通知”の活用 / Using notifications to handle the states of in-app subscriptions - Speaker Deck

お金の支払い状態と、サービスイン利用状態を合わせる

ボーリングによる
有効期限が切れたら最新状態を取得
だが、購読にはオンオフ以外がある

自動更新の停止
猶予期間
商品変更
試用期間
延期
一時停止
価格変更
subscription offer

ボーリングだけだと全部はカバーできない
通知ができる前からサービスやっている


定期課金の通知
webhookで受信
状態を更新
通知のログをDWHに保存
各サービスにはAmazon SNSで通知

Android
クックパッドでは主にAWSなのでAWSで受け取っている
SQLで履歴とかを取れるようになる
利用方法
猶予期間に入ったユーザーへの通知
自動更新をオフにしたユーザーを追う
問い合わせ対応
施策のための調査

Apple
httpのpostで来る
複数の内容が入っていたりする
スキーマが一定ではない
複数行みないと何があったかわからない
DWHにはgoogleに寄せるように保存
2019-11-22に新しい通知がリリースされてました


QAコーナー
・不正決済への対応
クライアント上での課金処理ログを送る、サーバーでのレシート検証
ログはサポート部署にも使える
サーバーでもログを取る、監査ログ
アプリそのものの改ざんとかも含む話になる
クックパッドのサービスは換金できないのでそこまでではない
・運用ふえない?
運用系はどんどん自動化したり、来る前に解決できるようにする
・SDK組み込むサポートどうしてる?
ガイドラインで対応、導入時支援
・appleレシートの仕様変更への対応できるようにしたは?iOS6
フィールドの型が変わったのでそこで判定、クラス内で抽象化
・通知のとりこぼしは?
ボーリングがメイン、通知はサブ
・異なる定期課金の抽象化は?アプリとカード
アプリ内課金は分けた
定期購読の管理は抽象化
・レガシーコードへの対応は
レガシーコードがあるのはクックパッド本体
データ移行して残ったデータは協力したりしてる
・複数決済からの重複課金処理への対応は
自動検知と重複課金
アプリで警告を出し、そこから問い合わせしてもらう


採用CMタイム


DMM meetup #14 行ってきました

DMM meetup #14 DMMを支えるプラットフォームの裏側 - connpass

決済周りを知りたくて参加して来ました。
以下メモです。


「プラットフォーム事業部の役割と目指す姿」

DMM、非上場会員数3000万
様々な事業がある

プラットフォームの役割分類
レコード、インサイト、エンゲージメント
採用してます



「ミライのデータエンジニア」
ミライのデータエンジニア - Speaker Deck

全社員から来るデータ活用要求、チームは6人
利用者の増加、雑なクエリ、増えるデータ量
セルフサービス化
gcpでデータ収集、データはオンプレのhadoop
このhadoopもgcp bigqueryに置くのを予定
募集してます



「巨大なレガシーコードをビッグデータでテストケースに変換する」
巨大なレガシーコードをビッグデータでテストケースに変換する - Speaker Deck

@rugamaga
商品情報持ってる、使われる場所が多く複雑だった。昔は。
直した手順。
ログをだすようにする
ログをテストケースにする
リファクタリングする

ロギング
aspect weaving
関数名と引数と戻り値、別途そのときのAPI,DBへのリクエスト
それらのデータを元にテストができる。大量だったのでサンプリングした。
よく使われる内容が優先される。
2人4ヶ月でレガシーシステムを置き換えられた。
募集中




「月間140億円の売上を支えるペイメントサービスの挑戦」

支払い機能、ポイント
クレジットカード
月間140億円、リクエスト2.3億
4チーム33人

10年で300事業のために

キーワード
10分でサービスイン
独立して利用できる
大量のリクエストを捌ける
データマイニングで情報を提供できる

最近つくったもの
payment gateway
支払い後、決済代行業者間からの通知を受け取る
api gateway, s3, aws lambda, sqs
まずs3にログ保存、sqsに入れて、別のlambdaがhook。dmmに送りつつ、workflowでリトライ処理。
非同期、サーバーレス。

intellij ultimateライセンスくれる
募集してます




「DMMの認証・会員情報プラットフォームの今とこれから」

金沢事業所
今年の7月に4事業所を統合
チーム33名を省略するとMAST

アカウント登録、登録、会員情報
利用できないとそのまま機会損失になる
理想は止まらないこと、いかに信頼性を向上させるか

起こりにくくする
影響範囲を小さくする
すぐに復旧できるようにする


検知は問い合わせベース

cloudwatch,datadog,kibanaによる検知、モニタリング
複数のサーバーにまたがるログ
slackからlambda経由でコマンドを実行できる
障害連絡もslackテンプレート化

PCがなくても対応できるようにした


MFA
マルチセッション
レガシー脱却
などなど

ユーザーにシームレス
時代の当たり前を提供したい



所感
独立した事業に共通基盤を提供すること、古くからあるシステムをどう改修するか、など、目的を持った上で改善したり入れ替えていくことが回そうとしたり回したという話がメイン。このジャンルの話は企業の考え方そのものともかかわるので面白い。
このサイトは
 Webアプリケーション開発のことや、iPhone・Android向けアプリ開発の話題がメインです。技術情報を取り扱っています。
 管理:えんたつ。twitter: @tattyamm
mimage
カテゴリ別アーカイブ
RSS
リンク
プログラミング本
アプリを作る時などに読んだ本
iPhoneプログラミングUIKit詳解リファレンス iPhoneプログラミングUIKit詳解リファレンス Android Layout Cookbook アプリの価値を高める開発テクニック パーフェクトPHP (PERFECT SERIES 3) JavaプログラミングBlack Book 2nd Edition (Black Bookシリーズ)
表記
当サイトではGoogle Analyticsを使用しております。詳細はこちらを御覧ください