@everzet氏のブログ記事より。例によって翻訳は無理なので気になったところだけ要約。
http://everzet.com/post/99045129766/introducing-modelling-by-example
- Cucumber、Behat、SpecFlowなどのGherkin-based BDD toolのシナリオをユビキタス言語で 書くといいんじゃない?
つまり、
Scenario: Showing delivery cost for a product on the basket page Given there is a product: | name | White Marker | | price | £5 | And I am on the "/catalogue" page When I click "Buy" in the "White Marker" product block And I go to the "/basket" page Then I should see a list with 1 product And the overall price should be shown as £9
ではなく、
Scenario: Getting the delivery cost for a single product under £10 Given a product named "White Marker" and priced £5 was added to the catalogue When I add the "White Marker" product from the catalogue to the picked up basket Then the overall basket price should be £9
こう書く。
そしてUIやインフラストラクチャー層を除く、ドメインモデルだけのstep definitionから実装を始める。 一部のシナリオをピックアップして、同じフィーチャーに対してエンドツーエンド用のstep definitionを書く。 つまり、1つのシナリオに対して2種類のstep definitionを書くことになる (このフィーチャーに対してはこのstep definitionを使ってね、ということを定義する"suites"という 機能をBehat v3に実装した。CucumberやSpecFlowを使っている人は中の人におねだりしよう)。
こうすることで、インフラストラクチャ層がコアドメインをするのを素早く発見できるようになる。
BDDとDDDは共にTranslation Costを排除しようとしているがレイヤーが異なっている。 BDDは対話、DDDはコードにフォーカスしている。二度翻訳するのは無駄だし間違うかもしれないよね。
インフラストラクチャー層はシナリオをパスするための手段だ。 全てのアプリケーションがMySQLへの接続を必要としているからではなく、 永続化レイヤーが欠けていることによってシナリオがパスしなくなったから永続化レイヤーをアプリケーションに追加するんだ