Documenting the Domain Modeling in Simple DSL
この記述の立ち位置を微妙によくわかっていない #??
Type Level Domain Modelingの前段階の、いわば仕様のプロトタイプというか、前段階のなぐり書き、ぐらいのイメージだったりするのだろうか？
というのも、最終的にはType Level Domain Modelingがその名の通り型レベルの仕様として継続してメンテする対象になる
Documenting the Domain Modeling in Simple DSLは初期の初期段階でしか使わないツールだったりするのだろうか
普通に、これを経由する必要なくない？と思っている
いったん自然言語寄りのDSLと、型、に仕様を書き下す
input/outputや副作用やイベントなどを意識する
代数的データ型を使う
クラス構造とかはガン無視
ドメインモデルをそのまま写す
細かい仕様であるvalidationなども書いていく
未定義な箇所に気づいたらひとまず
? とかで埋めておいて、Domain Expertに聞くなり、調べるなりするDocumentを書いていくことで、自分の理解も増えていく
大まかなWorkflowを表現していく
p.32の上の方のは自然言語よりだが、p.40では擬似コードで書かれている
p.40workflow "place order" =
input: OrderForm
output: ...
// step 1
do ValidateOrder
If order is invalid then:
add InvalidOrder to pile
stop
// step2
do PriceOrder
// step3
do SendAcknowledgementToCustomer
...ユビキタス言語の名詞に当たる概念の仕様を詳細化していく
p32bounder context: Order-Taking
data Order =
CustomerInfo
AND ShippingAddress
AND BillingAddress
AND list of OrderLines値の取りうる範囲などを記述
p36data WigetCode = string starting with "W" then 4 difitsわからないところは
? で埋めとくp.37data UnitQuantity = integer between 1 and ?Lifecycleの記述
ValidateされたOrderと、ValidateされてないOrderみたいなものが生じる場合は、その両方ともを区別して表現しておく
p38, p39data UnvalidatedOrder =
UnvalidateedCustomerInfo
AND UnvalidatedShippingAddress
...これで、注文のlifcycle内でのOrderの状態を全て仕様化できる
これは非エンジニアでも読んで理解できる
英語に抵抗がないのは大前提すぎるが
document化する際に、ある値の最小値、最大値などで未定義なことに気付いたら、ドメインエキスパートに聞く
細かい値のValidationのようなもの
一つの注文の型をライフサイクルごとに定義する
一つの注文は、未検証、検証済み、決済済みの3状態があり
一つの注文はレコード型になっている
これを各段階ごとに名前を付けて、型を用意する
その名前はユビキタス言語になるんやな
検証済みを表す
PricedOrder 型のみ請求金額の項目があるなどの差がある客が入力してから注文確定するまでの大きな注文の過程を小分けにして疑似コード化する
未検証、検証済み、決済済みのようなサブステップに分ける
各ステップでのinput/outputや、依存する外部の情報、どういうステップを踏むか、などを擬似コードで書く
大まかなworkflowは表現できるかもしれないが、細々とした機能の表現は難しくない
それはDomainModelingとちょっと意味合いがずれるのか？
この書籍内ではF#を使っているので、syntaxがじゃっかんF#に寄っているが、実装予定の言語によって、syntaxも変えていく感じなのかな
動的型付けの言語では不可能
というか代数的データ型がない言語だと厳しそう
これほんまにスケールするのか？
IDEのパワーを借りたい
スクボと良い感じに連携させられないものか
スクボの場合、IDE並の補完を効かせるためにはリンクに切る必要がある
そもそも、これ、自然言語で詳細に書いていくのと比べて何が良いんだ？
p.36~
色んな場所に書かれてる