Lean Architecture / DCI Evening参加メモ

mpdosaka.connpass.com

こちらに参加してきました。 会場を提供してくださったポート株式会社様、主催の@itemanさん@ksetaさんありがとうございました。

詳細は#dcitokyoにて。

f:id:hiroyuki-hanai:20171019015747j:plain:w300
オープニングの質問

short introduction

こちらにもある、ATMの口座振替を例にDCIのイントロダクション。

ATM動作のDumpを表示するプログラムを例に、

1. ObjectId -> 規則性がわからない
2. ClassName -> ◯◯Account, ◯◯Account, ◯◯Currencyの順に実行されていそう。
3. RoleName -> 構造がわかる

ピアジェのOperational ModelでRoleの判断基準を説明。

マトリックスの例でRoleがインジェクトされる感覚を説明。下記動画参照。

www.youtube.com

  • トリニティ=オブジェクト
  • ヘリの運転の仕方=(ヘリパイロットという)Role
  • Roleがトリニティ(HumanBeing Class)の手(instance method)をヘリを運転するのに使った。

trygve紹介

github.com

の紹介。

design by contractの話も少々。あるメソッドから別メソッドが呼ばれた場合に前提条件同士の間に矛盾が生じるパターンがあるとのこと。 (一時的に残高がマイナスになるようなケースかな。と理解。)

  • roleの中のthisはobject(role player)を指す
  • ビジネス上のトランザクションの責務は基本的にクラスの方が負う

User story/Use case

User story:
As a <user role>
I want <feature>
So I can <motivation>

User roles:  AccountHolder, BankEmployee,Citizens
they all want : transfer money, but different motivation
"context" can change
Core Senario(80%)
- choose source account
- choose destination account
- enter amount
- confirm transfer
Satellite Scenarios(20%)
ex)Amount > Balance

Lean/Agile

f:id:hiroyuki-hanai:20171019025237j:plain:w300
Agile/"does"/Revenue - Lean/"is"/Cost

どうやって開発していくか。

DomainAnalysis
->共通性/可変性分析
->Classes
->interfaces : skin of API(NO CODE)
when use case comes along, 
I write code Just In Time

最後に

f:id:hiroyuki-hanai:20171019020022j:plain:w300
サイン頂きました