FREITAGEEK

FREITAGが好きなエンジニア

「ついやってしまう」体験の作り方を読んだメモ

Twitterで見かけてつい買ってしまった、「ついやってしまう」体験のつくりかた、という本を読みました。

「ついやってしまう」体験のつくりかた 人を動かす「直感・驚き・物語」のしくみ

「ついやってしまう」体験のつくりかた 人を動かす「直感・驚き・物語」のしくみ

 

著者の方は、元任天堂であのWiiを手がけたこともあるとのこと。

どんな知見を得られるのだろうと、最初からかなりの期待感を持っていましたが、読んでいくとその期待をはるかに超えるほどの内容と構成であっという間に読み終わってしまいました。

今日はゲームをしないぞ!と決めてもついやってしまったり、やめどきがわからなくて気づいたら数時間経っていた、ということをだれしも1回は経験したことがあるのではないでしょうか?

そういった経験はなぜ起こるのか?そのためにどういう仕掛けを用意しているのかを解説されていて、また仕事においてその仕掛けを利用するためのポイントが書かれており、目からウロコな内容でした。

仕事の中で、チームメンバーのモチベーションを高めたいと思っているリーダーや、スクラムを導入しているチームでレトロスペクティブがうまくいかないと感じているスクラムマスター、プロダクトのデザインを担当しているデザイナーなど、人の気持ちを動かしたいと考えている人にはとても勉強になる本だと思います。

 

以下メモです。

全体マップを冒頭に提示して収集する体験を通して楽しんでもらう。穴埋めを徐々に開けていく感覚。

プレゼンの最初と最後で同じ問いかけをしてみる。最初はわからないけど、プレゼンの最後にはわかる、という体験をしてもらいたい。この体験によってプレゼンの価値を上げることができそう。

振り返りをしたくなるような文脈を作る。目的がないと振り返りをする楽しさがない。気づいたら振り返りをしている状態を作りたい。

タブーとされていることをたまに入れてみると、飽きや疲れを感じにくくなって新鮮な気持ちで取り組めそう。議論などシリアスな場面でお菓子を持ち込むとか。

自分の裁量でできる体験やプライベートな体験を入れてみる。自分で育てた感があると愛着が持てる。

コメントを書くということについて

コメントについて自分が考えることを書いていきます。

なぜコメントを書くのか?

まず、コメントを書く目的は、自分は以下の2点であると考えています。

  • コードを書いた開発者がコードで表現できない情報を読み手に伝えるため

  • 開発者が簡単にコードを理解して修正できるようにするため

1点目については、コメントがないとどういう目的で書かれたコードなのか、なぜその書き方を選んだのかということを理解できません。それによってコードの修正ができなくなってしまったり、修正によって想定していないバグを生み出してしまいます。

2点目については、コードが何をするものかがわかりづらいと、依存するコードを読んで再利用できるものか、副作用がないかを判断して修正、利用する必要が出てきてしまいます。

このようにコメントを書いて、暗黙的な知識を表出化し、コードを読みやすくすることで、システムの全体の複雑さを下げることができます。

なにをコメントとして書けばよいのか?

では、コメントを書くときにはどういった情報を書くべきでしょうか。 自分はコメントを書くときには、「コードに表せない情報」と「コードを読みやすくするための説明」を2つを書くようにしています。

コードに表せない情報とは、なぜこのコードを書いたか?なぜこのコードが必要なのか?という開発者の意図であったり、チームや組織の暗黙的なルールなどです。これらの情報を必要に応じてコメントとして残しておきます。

コードを読みやすくする情報とは、何をするコードなのか?、副作用のあるコードか?、修正する場合の影響範囲はどこか?などです。

良いコメントを書くためにはどうすればよいか?

コメントをなぜ書くのか?どんな情報を書くのか?について書いてきたので、最後はコメントをどうやって書くかについて書いていきたいと思います。

まず、コメントを読みやすいものにする方法としては、一貫性のあるコメントを書くことが大切です。JavaDocやJSDocなどテンプレートに沿ってコメントを書いたり、チームでコメントをどこに書くのか(interfaceなのか実装クラスなのか)どんな情報を書くのか、表記揺れのない用語を使うことなどを決めておくと読みやすいコメントを書くことができると思います。

また、コードを繰り返したコメントを書かないようにします。コードに出てくる単語をかいつまんだコメントを書いてしまうと、重要でない情報を持ったコメントになってしまいます。

外部モジュールの詳細については、外部モジュールの変更にコメントを対応させるのは大変なので、外部ドキュメントがある場合は、そのリンクをコメントとして残します。

コメントを書くためにはクラスやメソッドの抽象的な情報を理解する必要があるので、コメントを最初に書くことでシステムの設計を考えながらコードを書くことができます。後回しにしてしまうと、動くシステムに対してコメントをひたすら書く時間になってしまい、人によっては面白くない時間になってしまいます。

また、書いたコメントはコードレビューでチェックします。読み手がわかりづらいと感じたコードは、書いた人が後日読むときもわかりづらいものになっている可能性が高いので、レビューでコメントの書き方もチェックしてもらうようにしましょう。

ここまでコメントを書くことについて書いていきましたが、コードがシンプルな場合はもちろん無理して書く必要はありません。コメントを書きすぎてしまうとコードの表現力が貧弱になってしまい、重要な情報が埋もれてしまうからです。

最後に

コメントを書くときに、どういった目的で、どんな情報を、どういうことに気をつけながらコメントを書くか?ということをつらつら書いてみました。

コメントについては、「リーダブルコード」や「A Philosophy of Software Design」がとても勉強になるので、一読してみることをおすすめします。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

A Philosophy of Software Design

A Philosophy of Software Design

2019年上半期に買った技術的なもの

2019年上半期(4月 ~ 7月現在)に買った技術的なものを書いていきます。 忘備録も兼ねているので感想や新しく買ったものは逐一追記していきます。

Java データ構造とアルゴリズム基礎講座

今年に入って競技プログラミングをはじめたので、最初のステップとして購入しました。 配列, スタック/キュー, リスト, 木, グラフなどのデータ構造や、探索やソートの基本的な仕組みや計算量をわかりやすく説明されている本でした。

Java データ構造とアルゴリズム基礎講座

Java データ構造とアルゴリズム基礎講座

プログラミングコンテスト攻略のためのアルゴリズムとデータ構造

動的計画法、貪欲法まで読了

プログラミングコンテストチャレンジブック [第2版] ~問題解決のアルゴリズム活用力とコーディングテクニックを鍛える~

動的計画法、貪欲法まで読了

プログラミングコンテストチャレンジブック [第2版] ?問題解決のアルゴリズム活用力とコーディングテクニックを鍛える?

プログラミングコンテストチャレンジブック [第2版] ?問題解決のアルゴリズム活用力とコーディングテクニックを鍛える?

最強最速アルゴリズマー養成講座 プログラミングコンテストTopCoder攻略ガイド

動的計画法、貪欲法まで読了

エンジニアの知的生産術

業務ではスクラムマスターをやっているため、チームが学習する取り組みの参考になりそうと思い、本屋で衝動買いしました。 自分の学習のスタイルと比較して、うまくできていないなと感じているところをこの本を読みながら振り返ってみると面白いと思います。

Yubico セキュリティキー - U2F / FIDO2, USB-A, 2段階認証

FIDO認証の勉強のために購入しました。 FacebookGitHubなど既存のサービスにFIDO(U2F)で認証するのを遊んだりしました。 webAuthnを使ったサンプルアプリを作ってみるのもやってみたいです。

プログラミングの基礎

関数型言語を触ってみたいということと、改めて「プログラムを書く」ということについて学んでみたかったので購入しました。 OCamlを使って、変数や条件分岐などの基本的な文法〜駅の最短経路問題を解くまでを一通り体験できます。 プログラムを書く前に関数の目的を明確にする、テストケースを考える、入出力の型をコメントに書く、コードをモジュールに分ける、などコードを書くために必要な視点を学ぶことができるとても良い本でした。

プログラミングの基礎 ((Computer Science Library))

プログラミングの基礎 ((Computer Science Library))

Node.jsデザインパターン第2版

業務でNode.jsを使うことになったので、学習のために購入しました。 callback, Promise, async/awaitを使った非同期プログラミングのパターンやNode.jsでオブジェクト指向を取り入れたデザインパターンなどが紹介されていてとても勉強になりました。MQやAPIゲートウェイなどマイクロサービスにおけるパターンも紹介されているのでNode.jsをしっかりやってきた人にもおすすめです。

Node.jsデザインパターン 第2版

Node.jsデザインパターン 第2版

リーン・スタートアップ ムダのない起業プロセスでイノベーションを生みだす

積読中です。

リーン・スタートアップ

リーン・スタートアップ

THE TEAM 5つの法則

スクラムマスターとしてチームの状態を把握するヒントになるかなと思い購入しました。チームにおけるABCDE(Aim, Boarding, Communication, Decision, Engagement)の5つの法則が解説されています。行動目標、成果目標、意義目標など目標の粒度について紹介されていたり、チームで扱う業務の特性(状況変化、メンバーの連携度合い)など、現状のチームの状態を分析する指標を知ることができる本でした。自分の属するチームがどういう性質を持っていて、その性質に対して自分がどれぐらいフィットしていて、どういう改善ができるのかを考えるよい機会になりました。

THE TEAM 5つの法則 (NewsPicks Book)

THE TEAM 5つの法則 (NewsPicks Book)

世界でもっとも強力な9のアルゴリズム

積読中です。

世界でもっとも強力な9のアルゴリズム

世界でもっとも強力な9のアルゴリズム

Elsa Pro ライフタイム会員

英語発音練習アプリElsaのライフライム会員ライセンスを購入しました。 普段こういったアプリの学習を利用しないのですが、生涯利用できるライセンスがまさかの80%OFFということで即決で購入してしまいました。 まだ始めたばかりですが、レビューが高いだけあってアプリの動作も安定感がありますし、発音のチェックも特に気になるほど悪いところは見つかりません。1日5Lessonが目安となっていて、だいたい10分ぐらいあれば終わる量なので、これから習慣化目指してやっていこうと思います。

elsaspeak.com

FIDO認証を調べてみた

FIDO認証に興味があり、FIDO認証とはどういうものなのか、どういう仕組みで実現されているのか、を調べてみたので今回はそれについて書いていこうと思います。実装については触れていないのと、FIDO Allianceの仕様書をがっつり読み込んだわけではないので、ざっくりの概要レベルの説明になっているのでご容赦ください。

ゴール

  • FIDO認証の処理の流れがわかる

  • FIDO認証の仕様の分類がわかる

FIDOとは

FIDOとは、「Fast IDentity Online」の略で、FIDO Alliance - Open Authentication Standards More Secure than Passwordsによって仕様策定や普及推進が進められている、公開鍵認証に基づいた認証仕様です。

FIDOの用語

FIDOでは「Relying Party(RP)」という、ユーザの登録、認証を行うwebサイトや事業者を表すものと、「Authenticator (認証器)」という秘密鍵と公開鍵を生成, 保持するものが登場します。さらに認証器は、ローカルに実装されている内部認証器と、スマホなどのデバイスに実装されている外部認証器の2種類に分類されます。

FIDOの仕様

FIDOは以下の3種類の仕様が策定されています。

  • UAF

  • U2F

  • FIDO2

UAF

UAFは、「Universal Authentication Framework」の略で、パスワードレス型(所持+生体, etc)の認証仕様について策定されたものです。 UAFは、主にスマートフォンのアプリからの利用を想定したものになっています。

U2F

U2Fは、「Universal 2nd Factor」の略で、パスワード補完型(記憶+所持)の認証仕様について策定されたものです。 U2Fでは、パスワード認証の補完として生体認証やハードトークンの利用を想定したものになっています。

FIDO2

FIDO2は、外部認証器や内部認証器を用いた、パスワードレス型認証や多要素認証を実現するための仕様について策定されたものです。 FIDO2は、ブラウザ上でFIDO認証を実現するための標準APIであるWebAuthnと、認証器との通信プロトコルであるCTAPという仕様で構成されています。

WebAuthnは、正式には「W3C Web Authentication specification」と呼ばれるものでCTAPを用いてFIDO認証を行うための標準APIの仕様が記述されています。当初はFIDO Allianceによって仕様策定が進められていましたが、現在はW3Cで仕様策定が進められているようです。 またブラウザではChromeFirefoxなどがWebAuthnに対応しています。

CTAPは、Client-To-Authenticator-Protocolの略で認証器を用いてFIDO認証を行うための通信プロトコルの仕様が記述されています。 CTAPには、FIDO Security Keyを認証器として利用してFIDO認証をおこなうためのプロトコルであるCTAP1と、FIDO Security Keyに加えスマートフォンを認証器として利用してFIDO認証をおこなうためのプロトコルであるCTAP2の2種類があります。

FIDO認証の流れ(内部認証器を使った場合)

内部認証器を用いたFIDO認証の流れを「登録」と「ログイン」のフローに分けて書いてみます。

登録

  • ユーザがPCからRPにサービスを利用したい旨をリクエス

  • RPはチャレンジを生成してPCにチャレンジを返す

  • PC(Authenticator)は鍵ペアを生成して、チャレンジを秘密鍵で署名したものと公開鍵をRPに送信

  • RPはチャレンジや署名を検証して公開鍵を保存

ログイン

  • ユーザがPCからRPにログインしたい旨をリクエス

  • RPはチャレンジを生成してPCにチャレンジを返す

  • PCは送られてきたチャレンジを秘密鍵で署名してRPに送信

  • RPは署名を検証して認証をおこなう

最後に

FIDO認証(FIDO2)は、ブラウザなどのWebサイトでパスワードレスで認証をおこなう方法を実現するものとして期待されています。 現状、国内でもFIDO認証を導入した事例が出てきているので、今後さらにFIDOに注目していきたいと思います。(余力があればYubikeyなどを買ってFIDOの実装をしてみたい、、、)

参考資料

Hugoを使って生成した静的ページをGithub pagesにデプロイする

今回はHugoを使って生成した静的ページをGithub pagesにデプロイしてみようと思います。 公式サイトを参考にしているので、まずは公式サイトを読んで試してみてください。

やりたいこと

環境

環境は以下の通りです。git, hugoはすでにインストールしてある前提です。hugoが入っていないmacの人はbrew install hugoしましょう。

  • macOS 10.14.5

  • Git 2.19.1

  • hugo 0.55.6

手順

Githubに[username].github.ioを作成する

GitHubリポジトリを作成してcloneします。

$ git clone https://github.com/dais39/dais39.github.io.git

Githubに管理用のリポジトリを作成する(Hugoを導入するリポジトリ)

GitHubリポジトリを作成してcloneします。

$ git clone https://github.com/dais39/hugoadmin.git

$ cd hugoadmin

プロジェクトを作成

$ hugo new site myPage

$ cd myPage

$ ls 
archetypes  config.toml content     data    layouts     public      resources   static      themes

テーマを導入

https://themes.gohugo.io/ から自分の好きなテーマを探して、git submoduleでtheme/配下にテーマを紐づけます。 今回は以下のテンプレートを使います。

GitHub - jacobsun/edidor: A hugo theme that looks like an editor with a builtin style generator, INFINITE COLOR MODE from a market perspective. 😂

$ git submodule add https://github.com/jacobsun/edidor theme/editor

次にconfig.tomlの中身を修正して、テンプレートを有効にします。

$ echo 'theme = "editor"' >> config.toml

publicディレクトリを削除

ない場合はスキップでOK

$ rm -rf public

デプロイ先のリポジトリをpublicディレクトリと紐づける

$ git submodule add -b master git@github.com:dais39/dais39.github.io.git public

デプロイ用スクリプトの作成

以下の内容でdeploy.shをmyPage配下に作成します。 作成後ファイルの権限をchmod +x deploy.shで変更します。

#!/bin/bash

echo -e "\033[0;32mDeploying updates to GitHub...\033[0m"

# Build the project.
hugo # if using a theme, replace with `hugo -t <YOURTHEME>`

# Go To Public folder
cd public
# Add changes to git.
git add .

# Commit changes.
msg="rebuilding site `date`"
if [ $# -eq 1 ]
  then msg="$1"
fi
git commit -m "$msg"

# Push source and build repos.
git push origin master

# Come Back up to the Project Root
cd ..

デプロイ

./deploy.shを実行するとデプロイ先のリポジトリにpushされます。 https://[username].github.io にアクセスすると、ページが表示されていると思います。

参考資料

https://gohugo.io/hosting-and-deployment/hosting-on-github/

スクラムについて

今回は、Scrum Guideをはじめとした様々な書籍や資料を読んだり、業務でスクラムマスターとしてやっていく中で自分が腑に落ちた部分を書いていこうと思います。粗いところは少しずつ加筆して行こうと思っています。今まで読んできた主な書籍や資料は、参考資料として最後にまとめておきます。

そもそもアジャイルとは

スクラムとは

  • 現状を把握するフレームワーク
  • Scrum Guideに則る
  • スクラムは経験的プロセスを基本としている
    • 経験したことから学ぶ
    • 具体的に起きたこと、経験したことを元に業務を進めていく
    • 机上の空論にしてしまうと、結論がでない、メンバーの理解が得られない、背景の共通認識を得られない、といったことが起こりうる
  • 経験的プロセスは以下の3つの柱によって支えられている
    • 透明性
      • 何を作るか
      • 誰がやるか
      • いつやるか
      • なぜやるか
      • どうやってやるか
    • 検査
      • 成果物のレビュー
      • プロセスのレビュー
    • 適応
      • 問題に対して柔軟に対応する

スクラムの役割

  • ProductOwner
    • 「プロダクトのROIを最大化すること」に責任を持つ
    • ROIを常に考えて、最小の機能で最大の効果を得られるようプロダクトを導いていく
  • Team
    • 「ScrumTeamの生産性を最大化すること」に責任を持つ
  • ScrumMaster
    • 「ScrumTeamが実現したいことを実現する確率を最大化すること」に責任を持つ
    • 自走できるチームを作りあげることや、チームの問題を浮き彫りにしやすくする仕組みや支援を行う

スクラムイベント

  • スプリント
    • 目的
      • 決まったタイムボックスを設けることで、スクラムチームのベロシティ(生産性)を測定するため
    • 2~4週間のタイムボックス
    • プロダクトの方針と今やっていることに乖離が出た場合POがスプリントの中止をおこなうこともできる
  • スプリントプランニング
    • 目的
      • スクラムチームがスプリントで行うタスクの深い理解を得るためにおこなう
      • 開発チームが自律的に動く環境を作るため
    • プロダクトバックログの中から、スプリントで実現するアイテムを選ぶ
    • アイテムの数は、前スプリントまでの実績(ベロシティ)を参考にする
    • ベロシティを計測するために、アイテムを実現するための想定作業見積もりを相対的なポイントとして開発メンバーで決定する
    • プランニングポーカーがよく使われる
    • 開発メンバーのポイントが揃うまで議論する。議論することで認識のズレや仕様の理解を確認できる。
    • アイテムを実現するために必要な作業を開発メンバーで洗い出す
    • スプリントで達成する目標(Sprint Goal)を決める
    • リファインメントなどでDefinition of Doneをあらかじめ決めておく
  • デイリースクラム
    • 目的
      • 透明性を確保し、開発チームの状態を可視化するため
    • 同じ時間、同じ場所で毎日15分開催
    • スプリントゴールに対して、以下の観点を共有する
    • 昨日やったこと
    • 次の24時間で行うこと
    • 障害になっていること
    • デイリースクラムは開発メンバーのもの。雰囲気や発言に影響がでてしまうので、スクラムチーム以外の人間を入れるのは良くない
    • 開発メンバーがいないからといってスキップしてよいものではない
    • リモートでできないか、時間をずらしてできないか考える
    • どうしてもできない場合は、決まったフォーマットでSlackに流してもらう
  • プロダクトバックログリファインメント
    • 目的
      • プロダクトがどういう方向に進んでいくかをスクラムチーム全員で共有するため
    • プロダクトバックログアイテムの優先度の調整や、あいまいな要件を精査し、次のスプリントに容易に取り組める状態を作る
  • スプリントレトロスペクティブ
    • 目的
      • プロセスの検証と適応によって、スクラムチームの状態を改善するため
    • 2週間スプリントの場合、1.5時間
    • スプリントゴールに対してチームの良い点、悪い点、次へのアクションをスクラムチームで共有する
    • KPTなどのフレームワークをつかうことが多い
  • スプリントレビュー
    • 目的
      • スプリントの成果物がスプリントゴールを満たしているか検証しプロダクトの状態を把握するため
      • プロダクトバックログの状態についてスクラムチームで議論し、より深い理解を得るため
    • 2週間スプリントの場合、2時間
    • POやステークホルダーなどとスプリントのインクリメントをレビューし、プロダクトバックログの精査を行う
    • 最終的にdoneを判断するのはPOだが、DoDを定義しておくことでスクラムチーム全員が納得のいくdoneになる
    • POがレビュー時に気が付いてdoneを変更することは基本的になし

スクラムの成果物

  • プロダクトバックログ
    • プロダクトを実現するために必要な機能やユーザストーリーを優先度の高いもの順に並べたもの
    • 一つ一つの項目をプロダクトバックログアイテムと呼ぶ
    • それぞれのアイテムに対してDefinition of Doneを用意する
  • スプリントバックログ
  • スプリントで着手する予定のプロダクトバックログアイテムと、それを実現するための作業をまとめたもの

スクラムをなぜやるのか?

  • そもそもチームとしてどういう状態を目指しているのか?
    • 自己組織化されたチーム
    • 変化に対して柔軟に対応し、利益を生み出すチーム
  • 業界やメンバーなど、チームを取り巻く環境は常に変化する
    • 変化に柔軟に対応でき、変化によって発生した問題を解消できているならスクラムを導入する必要はない
    • 問題を浮き彫りにすることでチームに成長の機会を与えるフレームワーク

参考資料

アジャイルソフトウェア開発宣言

アジャイル宣言の背後にある原則

2017-Scrum-Guide-Japanese(PDF直リンクです)

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

SCRUM BOOT CAMP THE BOOK

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

ユーザーストーリーマッピング

Spring Frameworkの@Componentと@Controller,@Service,@Repositoryの違いを調べてみる

Springの@Component, @Controller, @Service, @Repositoryの違いについて気になったので調べてみます。

Stereotype Annotation

@Component, @Controller, @Service, @Repositoryなどは, Stereotypeアノテーションと呼ばれるものです。Stereotypeアノテーションとは、コンポーネントがアプリケーション内でどういう役割を担うかを表現するアノテーションです。 Springでは@Componentが付与されたクラスを、アプリケーション起動時にBeanとしてApplicationContextに登録します。@Controllerや@Service, @Repositoryなどはアノテーション内部で@Componentが付与されているため、@Componentと同じくクラスに付与することで、そのクラスはBeanとしてApplicationContextに登録されます。Stereotypeアノテーションは他にも@RestControllerや@Aspectなどがあります。

Spring Annotation Programming Model · spring-projects/spring-framework Wiki · GitHub

Spring Annotation Programming Model · spring-projects/spring-framework Wiki · GitHub

org.springframework.stereotype (Spring Framework 5.1.7.RELEASE API)

@Controller

@Controllerは、付与したクラスがMVCのコントローラの役割を持つことを表現します。機能面では@Componentと同じです。 @Controllerを使う場合は@RequestMappingや@ResponseBodyと一緒に使うことが多いと思います。ちなみに@ResponseBodyをコントローラクラスの描くメソッドに付与するのが面倒な場合は@RestControllerというstereotypeアノテーションを付与することで、デフォルトで@ResponseBodyアノテーションが各メソッドに付与されます。

Controller (Spring Framework 5.1.7.RELEASE API)

RestController (Spring Framework 5.1.7.RELEASE API)

@Service

@Serviceは、付与したクラスがDDD(ドメイン駆動設計)のサービスの役割、もしくはCoreJ2EEパターンの「ビジネスサービスファサード」の役割を持つことを表現します。裏側の複雑な処理を一つにまとめたシンプルなインターフェースを提供する役割と思ってもらえれば問題ないです。@Controllerと同じく機能面では@Componentと変わりません。Serviceという名前が汎用的なので、チームでどういう役割のときに付与するかは決めておいた方がよいです。

Service (Spring Framework 5.1.7.RELEASE API)

@Repository

@Repositoryは、付与したクラスがDDDのリポジトリの役割を持つことを表現します。また、PersistenceExceptionTranslationPostProcessorクラスをBean として登録することで、@Repositoryを付与したクラスで起きた例外をSpring独自のDataAccessExceptionという非チェック例外に自動で変換してくれます。

Repository (Spring Framework 5.1.7.RELEASE API)

PersistenceExceptionTranslationPostProcessor (Spring Framework 5.1.7.RELEASE API)

DataAccessException (Spring Framework 5.1.7.RELEASE API)