ayumu_aoの日記

SIerから事業会社に転職したエンジニアがなにかを垂れ流してます

ドメイン駆動設計についての学習ログ

自分なりの解釈内容をまとめてみる。

※長くならないようにできるだけ内容をまとめてるので不足が多々あることは承知

内容が正しいかは追って検証。

一言でいうと

ドメイン=業務・事業・利用者の関心事や興味、活動」を知る人が分析し設計・実装を行う

補足?: ドメインをただ知るのみでなく分析するためには、そのドメインの目的・背景までフォーカスを広げることでより理解が深まり、利用者に沿った設計を行うことができる。

噛み砕いてみる

現実の業務・事業をベースに考え、それらの核(本質)となる部分を抽象モデルとして表現する。

また、業務・事業の動作(やりたいこと・知りたいこと)をクラス名とメソッド名で表現する。

業務を適切な粒度でモデリングしそれを共通認識とした設計を行う。

適切な粒度って?

チーム・関係者が誤解を招かない粒度

具体的には?

モデルは一度書いたら終わりではない。ドメインへの知識・理解が深まるたびに修正・加筆を行う

※個人的には加筆は個々人で行うのではなくチームとして行い共通理解とするのがよいと考える

作成したモデルから実装をおこなう

必要な前提技術・知識・環境

まとめ(自分なりの考察)

一言でいうとに『「ドメイン=業務・事業・利用者の関心事や興味、活動」を知る人が分析し設計・実装を行う』と記載したが実際にはそれを一人でおこなう必要はないと考える。

一人ひとりがフルスタック(万能選手)を目指す必要はなくチームとしてフルスタック(万能チーム)であればよいのでチームに所属するメンバーのスキル・知識の総数でカバーする形をめざすのがよい。

では、ドメイン駆動開発に向いているチーム構成はどんなものかを考えてみる。

必要なのはドメインから必要なシステムを設計・構築できることなので業務サイドの人間は必須。

エンジニア、デザインナー、マーケターがそれぞれの役割(専門範囲)からアプローチできる環境ということで

分類 種別 人数 備考
事業サイド 1名〜
開発サイド エンジニア 1〜2名 必要に応じて排除
デザイナー 1〜2名 必要に応じて排除
マーケター 1〜2名 必要に応じて排除
ディレクター 1名 必要に応じて排除

最小構成だとこのくらいがよいのではないかなぁ。。

エンジニアだけの小チームを複数作って作業範囲分解していくということも否定はしないが、ドメインから遠のく気がするので

上記の構成を複数作ってドメインに近い環境を維持するのが良い(気がする)

AWS Summitに行ってきた!レポート※セッションメモ (2017/06/02)[Sansan]AWSが支えるEightのリコメンデーションエンジンの裏側

AWS Summit 2017/06/02 [Sansan]AWSが支えるEightのリコメンデーションエンジンの裏側

自己紹介

  • 鈴木康寛

サーバーレス×ビッグデータ

アジェンダ

  • Eightにおけるリコメンデーション
  • リコメンドアーキテクチャ刷新
  • リコメンドデータ洗い替え

■Eightにおけるリコメンデーション

Eight=個人向け名刺アプリ

「名刺をビジネスのつながり」に変える

入り口:名刺交換

日本全体の名刺交換の約10%をEightで担っている

約3億枚の名刺データ

名刺管理→ビジネスネットワークへ

キーワードは「つながり」

つながることで

  • 名刺情報のアップデータお
  • フィード投稿閲覧
  • メッセージ送受信

⇒ビジネスネットワークの活性化

リコメンデーション

利用者一人ひとりの指向に合わせコンテンツの推薦

Eightでは人物を推薦

名刺交換リクエストの承認率を上げるためのリコメンデーション

リコメンデーションエンジン

2年前からあったが誰が誰に何をしたかをひたすら蓄積し日時でバッチ処理で更新しCloudSearchに投げ込んでいた

しかし、

  • RedShift:無駄に複雑なクエリ

  • CloudSearch:全文検索として使ってなかった(スコア検索のみ)、更新までのレイテンシー

コストもそれなりにかかっていた⇒増えないつながり

  • パフォーマンス低下
  • オペレーションコスト高騰

■リコメンドアーキテクチャ刷新

リコメンドに最適なアーキテクチャとはなにか?

リコメンドの要とは 1. データ分析 2. アルゴリズム 3. リアルタイムフィードバック

キーワードとして「直近の出会いを大事に!」

鮮度が良いほどリクエストを承認しやすくなる

リアルタイムリコメンデーションを目指す!

開発期間は2ヶ月

条件:

  • 2ヶ月でできることにフォーカス
  • スケーラビリティ

やったこと

レーティングデータ

  • リアルタイム性を担保するために中間データを持つ

構想

  • ログ部分は既存のRedShiiftのデータを活用
  • 中間データ更新にKinesis+Lambdaが使えそう
  • 知見があるDynamoDBをストレージに
  • シャード数・キャパシティを上げることでスケーラビリティ

■サーバーレスアーキテクチャ

  • ストリーム :Kinesis、DynamoDB
  • コンシューマ:Lambda
  • ストレージ :RedShift、DymnamoDB、ElasticCache

サーバーレスは夢のツールではなかった。。。

サーバレスに対する誤解

  • パフォーマンス向上
  • オペレーションコストの低下

これは間違いだった。。。。

パフォーマンス

  • 分間1万件の1分間分のアクティビティが1時間たっても処理できない

解決方法 * まとめられる処理はまとめて処理する

※参考情報:Lambdaのメモリ設定はコンプピュータリソースの設定

オペレーションコスト

※処理の単純化を行いすぎるとFunctionが増加しすぎてしまう

(個人的な所感はRDBの正規化、非正規化問題に近いのかも)

ストリーム・コンシューマ問題

コンシューマとストリームを1:1にするとストリームが増えすぎてしまい管理できなくなったりコストがかかってしまう

分ける必要のないものはわけずにまとめる

パラメータにより処理を分岐する形にLambdaに複数処理をまとめる

■リコメンドデータの洗い替え

課題

レーティングデータの陳腐化

原因

  1. Eightサービス側のデータ構造の変更
  2. データ不整合の発生
  3. リコメンドルゴリズムの変更

発生すると今まで蓄積したものは無に帰る

解決策

全過去ログを集計してレーティングデータを作り直す!!

※DataPipelineを利用するとわりと簡易的にRedShiftにためたから可能

キーワード: * RedShiftCopyActivity * HiveActivity

※手順がスライドで紹介されてたので確認!

ダウンタイム無しで行うにはワークフロー管理が必要!!

StepFunctionsで解決!

※複数のLambdaを管理

StepFunctionsとDataPipeLineの組み合わせで行うために!

※スライド参照

Lambdaのタイムアウト問題

  • StepFunctionsのリトライ機能を使い完了していない場合はエラー扱いとして定間隔でリトライ
  • StepFunctionsのParallel、choiceを利用すると処理分岐ができる

DynamoDB Stream経由でCacheをひたすら高速生成

ダウンタイム無しで洗い替え

Lambda停止前と停止後で処理を分けるがどう切り分けるか?

指定時刻よりも新しいものを処理するという設定がLambdaでできる

約9500万件のデータの洗い替えが約9時間で完了

まとめ

サーバーレスの可能性

利点

  • 気軽さ
  • スケーラビリティ
  • 柔軟性

!!AWSを正しく使うことの価値!!

AWS Summitに行ってきた!レポート※セッションメモ (2017/06/02)[Sansan]AWSが支えるEightのリコメンデーションエンジンの裏側

AWS Summit 2017/06/02 [Sansan]AWSが支えるEightのリコメンデーションエンジンの裏側

自己紹介

  • 鈴木康寛

サーバーレス×ビッグデータ

アジェンダ

  • Eightにおけるリコメンデーション
  • リコメンドアーキテクチャ刷新
  • リコメンドデータ洗い替え
続きを読む

AWS Summitに行ってきた!レポート※セッションメモ (2017/06/02) [ワイヤ・アンド・ワイヤレス]AWS Lambdaを使ったモバイルバックエンドのサーバーレス開発事例

AWS Summit 2017/06/02 [ワイヤ・アンド・ワイヤレス]AWS Lambdaを使ったモバイルバックエンドのサーバーレス開発事例

自己紹介

  • 相馬 賢司

アジェンダ

  • TRAVEL JAPAN WiFi
  • サーバレス
  • APIGateWay/Lambda
  • テスト
  • デプロイ
  • ログ
  • まとめ
続きを読む

AWS Summitに行ってきた!レポート※セッションメモ (2017/06/01)Amazon Redshift テーブル設計詳細ガイド −分散スタイルとソートキーの決定方法−

AWS Summit 2017/06/01 Amazon Redshift テーブル設計詳細ガイド −分散スタイルとソートキーの決定方法−

※あとで資料が共有されるのでそれを見るのでメモ書きレベル

自己紹介

  • 柴田竜典

REdShiftを利用時のなやみ

  • クエリ性能をさらに向上させたい
  • 同時実行を上手にさばきたい
  • 料金を抑えたい などなど

クエリ性能向上に大切なことはなにか

  • 最良のソートキーの選択
  • 最適な分散スタイルの選択

なやみ

  • それぞれの方式のメリット、デメリットが正確に理解できていない
  • 統一感がない

アジェンダ

分散スタイル

  • なぜ重要なのか
  • キーの候補となる列の抽出
  • スタイルの決定
  • 最適なキーの決定

ソートキー * ソートキーについて * ソートキーの決定

続きを読む

AWS Summitに行ってきた!レポート※セッションメモ (2017/06/01)[メルカリ]Cloud connect the world as Glue

AWS Summit 2017/06/01 [メルカリ]Cloud connect the world as Glue

※あとで資料が共有されるのでそれを見るのでメモ書きレベル

自己紹介

  • 長野 雅広

SRETeamの紹介

  • Site Reliabillity Engineeringの略
  • プロダクト・サービスを横断してソフトウェアの信頼性を向上させる
  • いつでも快適かつ安全に利用できる「信頼性の高い」サービスの実現
  • 「新規サービス開発以外のエンジニアリングは全部やる」
  • 「インフラ」よりサービス指向

キーワード

  • エラーバジェット

アジェンダ

  • メルカリとは/世界3拠点での開発運用体制について
  • メルカリのアーキテクチャ
  • メルカリのグローバルインフラストラクチャ
続きを読む

AWS Summitに行ってきた!レポート※セッションメモ (2017/05/31)AmazonPayの仕組みと実装方法

【ライブコーディングも実施】AmazonPayの仕組みと実装方法

自己紹介

  • ジョナサン
  • 吉村周造

アジェンダ

続きを読む