コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

『ドメイン駆動設計 本格入門』に行ってきたよメモ

現場で役立つシステム設計の原則でお馴染み、増田さんのDDDの話ちゃんと聞いたことなかったのでドメイン駆動設計 本格入門に行ってきたよメモ

公演の内容


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

感想

3つの観点への変換

ドメインロジックをビジネスルール、ドメインモデルを計算モデルとして置き換えるという考えはなるほどなーという感じで思えた。またオブジェクト指向も根幹の部分である型に注目することで、一番コアな部分を説明しているという風に感じた。

ビジネスルールの分解も値オブジェクト、enum、コレクションのカプセル化と表現していて値オブジェクトとカタログ的な部分は書籍の記憶もありすんなり理解できたがenumで分解していく部分に関しては感覚ではわかるが人に説明するときにちゃんと説明できなそうな部分なのでエヴァンス本などで補強したく思った。

契約による設計をassetではなく値オブジェクトによる型での宣言という考えはなるほどなと思わせる部分が多く、基本的にnullを許容しないkotlinやswiftとあわせて考えるとかなり有用な考え方になると感じた。

手続き型(トランザクション)の部分をなるべく値オブジェクトに寄せる、手続きになるようなものはオブジェクトにするという部分に関してもいまいちピンと来ておらず

  • 引数に値オブジェクトの連鎖が続くと相互依存の強いものになってしまうのではないか
  • 手続きになる部分はアプリケーションレイヤに書くのか?

という疑問は残ったので、ここらへんは自身で書いて行くしか無いのかなという部分だった

エヴァンス本の解釈、読み解き方

エヴァンス本に関して語られるなかで印象的に残ったのが

  • ドメイン駆動設計の書籍において「実践ドメイン駆動設計」もあがるが、解釈が違う部分もあるのでそこは気を配るべき
  • 特定のワードに関してはかなり大きく取り上げられすぎている部分を感じる

という2点で、セットで語られることが多いIDDD本に関して解釈が違うという見解は初めて聞いた部分もあり、原典にちかいエヴァンス本の見え方や見解が人によって異なる部分は改めて垣間見た気がした。

また3部と4部に関しては改めて読む切り口を提示されたので読み直してみようと思う。

レガシーと向き合った事例とドメインを見つけ出す作業

レガシーコードと向き合うときにどう取り組んでいったかという話をされていて、DDDをやる上では本当に業務と向き合うということが大事ということを考えさせられた。

動いているプロセスや業務に携わっている人とのヒアリングなどコミュニケーションを重ねることで実現できるジャンルではあるし、別の勉強会で話されていたラーニング・パターン隠れた関係性を見つけ出すというような思考のテクニックも駆使していくことで理解が深められるんだろうなと感じた。

ドメイン駆動設計の使い手から見るマイクロサービス

ドメイン駆動設計を長年手がけられてきた増田さんが語るマイクロサービスは、Webサービス文脈で語られているアプローチとは異なる部分もあるなと思わせながらも、同じ部分もいくつかあり「必要になったタイミングで分割をはじめる」などは共通の見解なのだなと感じた。

その後紹介されたVETRO分析などは初めて聞いた部分ですし、エンタープライズに身を置く方だからこそ出る観点だし、非常に勉強になった。

増田さんの経験値から来るもの

以前違う勉強会でも話していたが、基本増田さんの話は実体験であり、個人の見解であるという注釈が絶対つけられる。逆にそのポジションを明確にしてくれるので持ち帰る部分と持ちかるべきか考える部分を自身に問いかけることができる。

その自分自身へのキャッチアップすべきかの問いかけがさらなる理解や自身の環境においてどう適用すべきかを考えさせてくれるので良いな、という場面が多いです。

関連リンク


全体を通しての感想

普段はBtoCのアプリケーションをやっているので「ビジネスルール」という観点ではなく、企画者の思いつくルールを具現化するという出来上がってない法則に則ってサービスを作っているので、ある種できあがっている業務プロセスを分解するのとは違うことをやっているので、毛色が違うと思う部分も多々ありました。しかしながら自分が普段触れない分野の話なので大変学びが多かったです。また機会があれば次回も参加したいです。(今回は辞退したけど布教用にもう一冊ほしかったです(笑))

ある事柄についてみんなでどう思っているかを指で表現する『ファイブフィンガー』についてざっとまとめる

書籍カイゼンジャーニーにて紹介されていたテクニックを自分なりに咀嚼し直してみる。

「ファイブフィンガー」とは

チーム内での問題を見つけ出すために、ある事柄において個人個人がどう思っているかを5本の指で表現する手法。

取り組みの良し悪しなどに関して質問を投げかけて考えてもらう。個々人の考え化がまとまるのを待ってから指の本数で状況を表してもらう、本数の意味合いとしては…

  • 5本:とてもうまくやれている
  • 4本:うまくやれている 
  • 3本:可もなく不可もなく
  • 2本:少し不安
  • 1本:全く駄目

というような形で3本が真ん中に来るような5段階評定で意思表示をする。

意思表示が終わったら本数の少ないメンバーから話を聞いていく。

効果

  • 本数の少ないメンバーは少なからず問題に感じているので、それに対してスポットライトをあてて話す機会をつくることができる
  • 逆に本数の多いメンバーは本数の少ない人をカバーできるアイデアを持っているかもしれないのでそこですぐに解決することができるかもしれない

注意点

  • 問題を見つけ出す場で、誰かを吊るしあげる場ではないのでネガティブなことを言うメンバーを咎めるようなことがないような場作りが大事
  • コミュニケーションの活発化が目的なので、リーダーなどはそこらへんを促進できる動きをできるとよい

個人的なコメント

プランニングポーカーの工数のすり合わせ機能を抽出したものな気がして、その事柄に関して問題と思ってない人と思っている人で何が違うのかを埋めることで知識をすり合わせれば解決する問題は解決に導き、全員が問題に思っていることはみんなで意識をそこに向けられる良い手法だなと思いました。

参考リンク

出典元

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

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

RubocopのBundler/OrderedGemsは空行やコメント行があると反応しなくなる

rubocopってgemの順番にイチイチつっこんできますよね…みたいな記憶だけがあって実際には言われないな…みたいな話で気づいたメモ、原理までは追えなかったのでとりあえず。

前提

Bundler/OrderedGems が default で enable なので反応する

当該コード:rubocop/ordered_gems.rb at master · rubocop-hq/rubocop

動き

# frozen_string_literal: true

source 'https://rubygems.org'
git_source(:github) { |repo| "https://github.com/#{repo}.git" }

ruby '2.5.0'

gem 'jbuilder', '~> 2.5'
gem 'rails', '~> 5.2.2'
gem 'mysql2', '>= 0.4.4', '< 0.6.0'

#後略

みたいなものがあると

$ bundle exec rubocop Gemfile 
Inspecting 1 file
C

Offenses:

Gemfile:10:1: C: Bundler/OrderedGems: Gems should be sorted in an alphabetical order within their section of the Gemfile. Gem mysql2 should appear before rails.
gem 'mysql2', '>= 0.4.4', '< 0.6.0'
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

のように反応し、railsの前にしろといわれる。

書き方

空行なしで連なっているものだけ反応するので、空行かコメントを加える。すなわち…

gem 'jbuilder', '~> 2.5'
gem 'rails', '~> 5.2.2'

gem 'mysql2', '>= 0.4.4', '< 0.6.0'

こうすると反応しなくなる

参考

RailsでフォームからじゃないPOSTリクエスト時にrenderしてみる

特異な要望を頂いたのでRailsというフレームワーク的に対応しているかの実証実験メモ。

大前提

こんな実装はおすすめできないので、素直にHTMLを表示するだけならGETリクエストを使うようにしてください…。

環境

$ bin/rails -v
Rails 5.2.2

検証

ControllerとViewをつくる

▼ app/controllers/articles_controller.rb

class ArticlesController < ApplicationController
  # 直接curlするとCSRFトークンがないエラーが出てしまうのでスキップ指定
  protect_from_forgery except: :create

  def create
    render
  end
end

※たぶんCSRFトークンを事前に知らせるのは難易度高いので別の方法でセキュリティは担保する

▼app/views/articles/create.html.erb

<h1>Articles#create</h1>
<p>post and render html!!!!!</p>

※layoutとかは説明省略

curlしてみる

localhostで起動

$ bin/rails s

curlしてみる

$ curl -X POST localhost:3000/articles
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
  <HEAD><TITLE>Length Required</TITLE></HEAD>
  <BODY>
    <H1>Length Required</H1>
    WEBrick::HTTPStatus::LengthRequired
    <HR>
    <ADDRESS>
     WEBrick/1.4.2 (Ruby/2.5.0/2017-12-25) at
     localhost:3000
    </ADDRESS>
  </BODY>
</HTML>

length-headerがないと怒られる、ので適当にパラメータをつける

$ curl -X POST localhost:3000/articles -d "example=test"
<!DOCTYPE html>
<html>
  <head>
    <title>SampleApp</title>
    <meta name="csrf-param" content="authenticity_token" />
<meta name="csrf-token" content="9gBv+fU3rLT7r57+yi6C/mZIGN8Pw4DNsdkdJTrrRwmxu4ftWOElOQGJIFg11hwwbaD8dH2wE5crqgFYpp2gew==" />


    <link rel="stylesheet" media="all" href="/stylesheets/application.css" />
  </head>

  <body>
    <h1>Articles#create</h1>
<p>post and render html!!!!!</p>

  </body>
</html>

取得できた。CSRFトークンもつく。

参考

rubyでpng画像をBASE64化してHTMLに貼り付ける

話には聞いていたがやったことないのでやってみる。

環境

$ ruby -v
ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-darwin18]

やり方

png画像をBASE64に変換する

こんな感じで対象画像をtarget.pngという名前で配置

$ tree
.
├── convert.rb
└── target.png

convert.rbは以下

require 'base64'

binary_data = File.read("target.png")
p Base64.strict_encode64(binary_data)

実行すると以下

$ ruby convert.rb 
"iVBORw0KGgoAAAANSUhEUgAAADIAAAAyCAMAAAAp4XiDAAAABGdBTUEAALGPC/xhBQAAACBjSFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAA3lBMVEU9Q7jT1O////+xs+JKUL3Fx+ry8vrExuo+RLjx8vpSV8BGTLtDSbqkp96usOFCSLpPVb/29vzY2fHDxelOU77i4/RbYMN/g9A/RblJT7zk5PVfZMViZsXOz+1LUL23uuW8vub39/xESrv19fu5u+WXmtmRlNdQVb/3+PxFSrtITrzk5fXKy+xjaMZpbshLUb3t7fhZXsLj5PVRVr/n5/be3/NrcMnu7/lcYcNCR7qrreCwsuKprOCnqd8/RLnLzex+gtCmqd6Okdbw8PlITbzHyOrq6/eUl9hHTbxrb8n+VD9KAAAAAWJLR0QCZgt8ZAAAAAd0SU1FB+MDFQY4O956N5wAAACwSURBVEjH7dC3EoJAFIXhAyqgsigGzIKYEMw55/j+L+TAoGOxBfb7dff83QUYhmH+wfE8HwLCEUEMBytSNBaPywBREgpBoJJUU2o6A2Q1aFl3yHH5QrFEKx/lSrmqG0DNhFn3lkZTb9HLj7YAWDI6lnfZTleiF1+vDwyGQHGE0dhbJtOZTC+++WK5Wm+ALZHIzh32h+PmRC3fv5ydi34FCre7aLvDw8DTedEKwzBMYG/7KBXMD75mAgAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAxOS0wMy0yMVQxNTo1Njo1OSswOTowMFEJEK0AAAAldEVYdGRhdGU6bW9kaWZ5ADIwMTktMDMtMjFUMTU6NTY6NTkrMDk6MDAgVKgRAAAAAElFTkSuQmCC"

HTML上に記述する

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADIAAAAyCAMAAAAp4XiDAAAABGdBTUEAALGPC/xhBQAAACBjSFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAA3lBMVEU9Q7jT1O////+xs+JKUL3Fx+ry8vrExuo+RLjx8vpSV8BGTLtDSbqkp96usOFCSLpPVb/29vzY2fHDxelOU77i4/RbYMN/g9A/RblJT7zk5PVfZMViZsXOz+1LUL23uuW8vub39/xESrv19fu5u+WXmtmRlNdQVb/3+PxFSrtITrzk5fXKy+xjaMZpbshLUb3t7fhZXsLj5PVRVr/n5/be3/NrcMnu7/lcYcNCR7qrreCwsuKprOCnqd8/RLnLzex+gtCmqd6Okdbw8PlITbzHyOrq6/eUl9hHTbxrb8n+VD9KAAAAAWJLR0QCZgt8ZAAAAAd0SU1FB+MDFQY4O956N5wAAACwSURBVEjH7dC3EoJAFIXhAyqgsigGzIKYEMw55/j+L+TAoGOxBfb7dff83QUYhmH+wfE8HwLCEUEMBytSNBaPywBREgpBoJJUU2o6A2Q1aFl3yHH5QrFEKx/lSrmqG0DNhFn3lkZTb9HLj7YAWDI6lnfZTleiF1+vDwyGQHGE0dhbJtOZTC+++WK5Wm+ALZHIzh32h+PmRC3fv5ydi34FCre7aLvDw8DTedEKwzBMYG/7KBXMD75mAgAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAxOS0wMy0yMVQxNTo1Njo1OSswOTowMFEJEK0AAAAldEVYdGRhdGU6bW9kaWZ5ADIwMTktMDMtMjFUMTU6NTY6NTkrMDk6MDAgVKgRAAAAAElFTkSuQmCC" />

上記のようにimageを指定すると埋め込まれる

表記例(自分のGithubページ)

余談

画像サイズは問わないが、でかくなるものではあるので扱いに気をつける必要がある

参考リンク

SlackにGithubを設定するときのコマンド

だいたいいつもやり方を忘れるのでチートシート

やり方

GitHubプラグインを入れる

下部のAppから

f:id:shinkufencer:20190318230718p:plain

GitHubを選択して

f:id:shinkufencer:20190318230730p:plain

インストール

f:id:shinkufencer:20190318230743p:plain

対象のリポジトリを選択する

仮に shinkufencer/moshi2police を対象にしたい場合は

/github subscribe shinkufencer/moshi2police

と打てば実行される

コメントとレビューを表示するようにする

デフォルトだと「レビューされたとき」と「コメントがついたとき」が流れてこないので、微妙に見づらいので追加する

/github subscribe shinkufencer/moshi2police reviews comments

参考リンク

マジックナンバーの起源をざっと調べてみた

英語のWikipediaに書いてあったので雑学的なメモ

出典

Magic number (programming) - Wikipedia

Wikipedia曰く

詳しく理解できていない部分は多分にあるが、Unixの第6版のときにヘッダの分岐構造における定数値において、理解しづらい定数値の値をセットしているところがあり、それを ux_mag と定義されたところでマジックナンバーと呼ばれるようになったのが起源らしい。コードみたら確かに /* magic number */ ってコメントが有る。

関連リンク