ドメイン駆動設計 本格入門レポ

行ってきたのでレポ。

資料

概要と感想

スライドの各章ごとに概要と感想をメモする。

ドメイン駆動設計の考え方

ドメイン駆動設計でなぜ作るか簡潔に述べている。
とくに、コードの変更を安全で楽にするということは、セキュリティ向上、性能改善、ビジネス要求の素早い実現にもつながるという説明がためになった。
言われてみれば当然かもしれないが、このような話題はエンジニア視点で語られることが多く、コードの変更が容易になった先の視点が抜けがちなので、ビジネス視点での有用性を説明する際に積極的に使っていこうと思った。

ドメイン駆動設計を理解する3つのキーワード

ドメイン駆動設計の文脈において頻出するキーワードを、焦点を絞りより具体化して説明している。
この章は『現場で役立つシステム設計の原則』で語られている部分がいくつかあったので事前に読んでおいてよかった。(まだ読んでいる途中)
1、2、3、4、5章に重複している部分があるので相互に読むとより理解できると思う。

3つのキーワード(ビジネスルール、計算モデル、型指向のプログラミング)についてかなり大雑把にまとめると、

  • ビジネスルールとは金額、数量、期日などの計算と判定である。それらは、状態、区分、タイミングなどにより複雑に条件分岐する。
    例:商品種別、有効期間、キャンセル可能条件など
  • ビジネスルールは計算モデル(計算式、判定式、条件分岐)であり、Fact、Rule、Goalに分類してモデル化できる
  • ビジネスルールはに登場する値は専用の型を作り整理する(型指向のプログラミング)
  • ビジネスルールの設計パターンとして

が挙げられる。具体的にはスライド参照。

特に以下のような具体例が参考になった。

メソッド名は標準クラスでよく見るものなので、値オブジェクトのメソッド名をつける際には参考にしていきたい。
これら以外の特殊な名前になるときは値オブジェクトのクラス設計を見直しても良さそうだと感じた。

エヴァンス本のススメ

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)


上記エヴァンス本で

  • 誤解されがちな概念
  • 全体構成と要点
  • 読み進め方

について述べられている。
とくにエヴァンス本の読み進め方はDDDに興味を持ってこれから読み進める人は読んでおくと良いと思った。
すでに最初から読みすすめているので、もう少し早く知りたかった…

レガシーに立ち向かう

ドメイン駆動設計の手法で、レガシーシステムに対して、

  • どのように現状の調査分析をおこなうか?
  • 手がかりをもとにどのように整理していくか?

その具体的な方法について述べられている。
特に心の準備編ではあるあるなことが多かった。

マイクロサービスとドメイン駆動設計

マイクロサービスとドメイン駆動設計の関連性について、

  • マイクロサービスの4軸に分けた分割方針
  • 相互のアーキテクチャの特性と移行タイミング
  • マイクロサービス化と相性の良いアプリケーション層・データベースの分析/設計手法

について述べられている。

継続的に分割の見直しができるかどうか?が重要だと感じた。

全体の感想とメモ

  • 具体例を通してエヴァンス本を読んでいたときよりもドメイン駆動設計の解像度があがった(特にビジネスルールのモデル化や設計パターンなど)
  • とにかく値オブジェクトが大事
  • ブレイクスルーについて語られるときもほとんど値オブジェクトの話
  • DDDは長く継続して運用されるシステムに特に効果がある
  • DDD本は通読するより全体を把握して都度読み返す方法がよさそう
  • 発表前に「これは正解ではなく、自分の体験・経験である」と前置きがあり、参加者の思考・議論を促していたのがよかった
  • 現場で役立つシステム設計の原則9章と関連したエピソード(おそらく9章を書くきっかけになったもの)が披露されて、他人に説明して納得してもらうスキルも必要だと感じた
  • Tryは担当システムのビジネスルールとその値オブジェクトの分析、整理

CI/CD Test Night #3に参加してきた

概要

いってきたのでメモ。
testnight.connpass.com
Tryを中心に書いていく。
共通していることが多いので、後半になるにつれTryが少なめ。

LTメモ

fastlaneとBitriseで構築するiOSのCI/CDレシピ

https://speakerdeck.com/rockname/cd-recipe-constructed-with-fastlane-and-bitrise

やったことある

  • Slackからデプロイ
    SlackでCode Deploy叩く
  • リモートでCI結果確認
    CI結果のSlack通知
  • カバレッジ計測
    mocha+nyc

Try

  • ビルドアクションのソース管理
  • 毎週パッケージのアップデートを検知しPRを自動で作成
  • ビルド時間とカバレッジを毎日計測して改善

Automate All the Things

https://t.co/M90bD94WLr?amp=1

やったことある

Try

  • cspellでスペルチェック
    無視リストがあるので有効活用する
  • CI結果をPRにポストする
    Dangerでやっているとのこと。 SlackにはポストしていたがPRで一覧できるのはいいかも?
  • コードカバレッジをPRにポストする
    同上
  • 画面キャプチャを撮ってPRにポストする
    スナップショットテスト。テスト走らせなくてもまずはポストするだけでも気づけることはありそう。
  • CIの速度改善、ビルド生成物をキャッシュして速度改善する

10分でわかるGitHub Actions

https://speakerdeck.com/ikeike443/10fen-defen-rugithub-actions-08a47f83-0acb-4fd3-9615-c7ec22cf0f8c

Try

  • GitHubActions触ってみる
    Delete marged branchあたりはすぐ試せそう。
    テスト、ビルド、デプロイ、リリース作成あたりも試したい。
    CircleCIとの棲み分けどうなるのか気になる。

Jenkinsのつらみを軽減した話

https://speakerdeck.com/theoden9014/jenkins-falseturamiwoqing-jian-sitahua

やったことある

  • Ansible

Try

  • Ansibleの検証環境をVagrantで作ってみる

GASを使ってBitriseを手軽に拡張する(仮)

https://speakerdeck.com/kwzr/ciwogasdeji-sok-de-nigai-shan-sitaraxing-seninatuta

Try

  • ビルド状況の計測

CI/CDと継続的ワークフロー改善

https://speakerdeck.com/gaussbeam/cdtoji-sok-de-wakuhurogai-shan

GitHub と連携する CI を作る

https://speakerdeck.com/duck8823/github-tolian-xi-suru-ci-wozuo-ru

社内の遊休PCをAzure PipelinesでCI/CDに活用しよう

https://www.slideshare.net/shinyanakajima37/pcazurepipelinescicd

まとめ

  • CIはスモールスタートではじめてみる
  • CI/CDを計測して改善していく
  • 機械的な指摘やパッケージのアップデートのPRはCIでやる
  • ビルド時にやっていることはコード化する

懇親会雑談メモ

  • cspell導入コスト低そう
  • ローカルとCIで静的解析のダブルチェック
  • ローカルで静的解析はコード量おおくなると時間かかるからやらない
  • 上位のテストはコストかかるので後回しになりがち
  • スナップショットテストはコスト低め
  • iOSアプリはwebより巻き戻しが大変
  • カバレッジ、ビルド時間はみんな計測してて、定期的に改善する会やる
  • 何を基準に自動化するか?早すぎる自動化はきつい。作業をおこなっている回数や同じ作業をおこなっている人数を見る。

AnsibleでFailed to connect to the host via ssh: Permission deniedのエラーが出たとき

概要

AnsibleでFailed to connect to the host via ssh: Permission deniedが出た。

$ansible all -i inventory -m ping
host | UNREACHABLE! => {
    "changed": false, 
    "msg": "Failed to connect to the host via ssh: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).\r\n", 
    "unreachable": true
}

環境

$ansible --version
ansible 2.6.8

対応

パスワードレスsshできるように公開鍵を対象ホストに設置した。
チェックポイント

  • パスワードレスssh接続できるか試す
  • ansible all -i inventory -m pingコマンドを試す

対応後のレスポンスはこうなる。

$ansible all -i inventory -m ping
host | SUCCESS => {
    "changed": false, 
    "ping": "pong"
}

AnsibleホストでAnsibleを実行するユーザと、リモートホストで作業するユーザを考慮する。

c.f. https://docs.ansible.com/ansible/latest/user_guide/intro_getting_started.html#id5

2018年後半ふんわりまとめ

2018年前半まとめ(一部) - mMQnaZ7vL2DWkoU’s diary

続き

8月からチーム移動があった。
後半はざっくりまとめる。  

やっていること

  • レガシープロダクトの引き継ぎ*4
    プロダクトの分析
    改善点の洗い出し  
  • Domain Driven Develpomentでのリプレイス開発*1
    エヴァンス本の勉強会
    旧仕様のユビキタス言語の洗い出し
  • 新チームでのスクラムイベントの導入  
  • 新人教育  

 

チケット化したものの一部

  • ログ基盤の構築
  • アクセス解析の導入
  • パフォーマンスモニタリングの導入
  • テスト自動化
  • テストピラミッドによるテストレベルの分離
  • CI/CDフローの改善
  • バグをいくつか発見したのでそれの改善
  • Promise hellの改善
  • linter,formatterの導入
  • ローカル開発環境の構築
  • インフラ周りの負債返却
  • ブランチ運用の改善  

 

個人でやっていたこと 

  • GolangCLIツール作った
    QiitaAPIを使った。
  • Ansibleの理解を深めた
    ベストプラクティス、テスト、CI/CDフローなど。
  • JAWS-UG 金沢でしっかりめの登壇
  • Kanazawa.rbでLT

以上。

後半もいろいろ学ばせてもらった。
来年もやっていきたいと思います。

2018年前半まとめ(一部)

JIRAで管理されたタスクから2018年を振り返ってみる。
チケット化されたもののみ書き出してみると、意外と作業量にばらつきがある印象だった。
ISSUEをチェックしようと思ったら前チームのGitHubEnterpriseのOrgから抹消されたので、過去のISSUEが見れなくなってた…

1月

  • Kibanaによるログの可視化
  • Chatops(Slack)によるAWSリソースの操作 これによりリリース作業が簡単になった。
  • jmeterによる負荷試験。手順に従って実施したので記憶が薄い
  • node-poolのリソース開放エラー調査
  • CloudFormatioinテンプレートの更新
  • Node.jsのバージョンアップ

など

2月

  • 障害報告/クローズ基準のまとめ作成
  • 軽微障害の復旧報告用テンプレート作成 Slackのslashコマンドで呼び出せるようにした。
  • CodeDeployのデプロイロールバックのSlack通知
  • 社内npmレジストリの構築(依頼してリポジトリの挙動確認)

など

3月

  • lint-stagedの導入
  • ESLintのルールの見直し
  • 社内npmのパッケージ移行
  • 内製パッケージのバージョニングのフローを考える

など
パッケージ移行やルールの変更作業など、地道な作業が多かった。

4月

  • 新規ページの実装
  • VisualRegressionテストの導入検討
    BackstopJSとかreg-suitとか触った
  • E2Eテストの改善

など

5月

  • Amazon API Gatewayの実装
  • StatusCakeによる外形監視の導入
  • 新規機能のデータストアの設計
  • 新規機能のデータ保存フローの検討
  • 新規機能のデータ量の見積もり

など

6月

  • 新規機能の外部API利用フローの設計作業
  • AWS Cost Explorerを使ったAWS利用料金のSlack通知

など

DockerfileのWORKDIRに$HOMEと書いても認識されないとき

環境

$docker --version
Docker version 18.09.0, build 4d60db4

概要

DockerfileのWORKDIRはDockerfileのENVで定義された環境変数しか使えないので気をつけましょう

ドキュメント

https://docs.docker.com/engine/reference/builder/#workdir

You can only use environment variables explicitly set in the Dockerfile.

build結果

build失敗して気づくパターン

$HOME単体ならbuild失敗して気づける

Dockerfile

FROM alpine
WORKDIR $HOME

docker buildの結果

…
Step 2/5 : WORKDIR $HOME
cannot normalize nothing

build成功して気づかないパターン

定義されていない環境変数+パスが含まれているとbuild時に気づけない
Dockerfile

FROM alpine
WORKDIR $HOME/hoge
RUN pwd

docker buildの結果

Step 3/3 : RUN pwd
 ---> Running in 81645314a99f
/hoge
Removing intermediate container 81645314a99f
 ---> 1f8259c44e59
Successfully built 1f8259c44e59

チーム移行するときに抑えておくべきポイント

概要

チーム移行するときに抑えておくべきポイントをまとめる
システムによって特性は異なるので優先順位や、必要かどうかは変化する

チェックすべきポイント

リポジトリを事前に見せてもらう

これから関わるプロダクトがどういうものか?事前に確認する必要がある。

ナレッジが管理されているか?

チームで活動していく上で必要なドキュメントが揃っているか?更新されているか?参照しやすい・検索しやすい状態になっているか?

各種図が存在するか?更新されているか?

システム構成図、ER図、クラス図、サーバ一覧などがあるか?
pngなど編集できないようなファイル形式で作らない。
ない場合は、システムの理解や問題発見につながるので早めにつくる。

セキュリティ対策できているか?

基本的なセキュリティについて、対策できているならその理由をまとめておく。
対策できていない場合は、ユーザやシステムに被害が出ないように最優先で対応する。

障害は検知できているか?

障害が起きてもわからないという状況をさけるため、障害検知は優先的におこなうべき。

ログ集約・監視はしているか?

「サーバ入ってファイルを見る」のような運用は辛いので、ログ集約・監視はやっておきたい。

パフォーマンスモニタリングできているか?

自分たちのシステムは、普段どれくらいのリクエストが来るか?CPU・メモリ利用率はどれくらいの値か?把握しておくべき。
パフォーマンスの異常を検知することで、障害の早期発見・事前解決につながる。

テストは書いてあるか?

単体テスト結合テスト、統合テストは書いてあるか?

テストが充分でないと起こる不都合について

  • 単体テストの中で外部APIを呼び出したり、DB処理をおこなっているケース
    APIのテスト、DB処理のテストは必要だが、単体テストの中でおこなうと、テスト失敗の原因が分かりづらくなったり、単体テストに時間がかかるので分けるべき。
    さらにこのようテストをCI上でおこなうと、API呼び出しのためのトークンの登録なども必要になってくる。
  • 単体テストが書いていないケース
    コード変更の影響範囲がわかりづらい、結合テストが書いていないので検証に時間と労力がかかる。

CI・CDフローは整っているか?

自動テスト、自動デプロイできるようになっているか?
なるべく短い期間でデプロイするのが理想なので、デプロイに時間がかかったり、ミスが起きやすいフローになっている場合は修正する。

まとめ

これらの問題に対してチーム全体で話し合い、システムがどのような状況なのか?どこまでできるようにするのか?認識を合わせておく必要がある。
そうしないと、開発チーム間で認識の不一致が起きてしまう。