OOじゃないDDDについて

概要

モデリングについていろいろ - Togetterまとめを読んでいて、前にも何度か言ったことがあるけれど、もう一度言っておこうかー的な感じです。多分ブログには書いていませんでしたので。

端的に言えば、パイプ&フィルターパターンがアプリケーションドメインであるアプリケーションもあって、そういったものはオブジェクト指向より関数型的なほうがうまく適合する可能性もあるという話。

DDDとプログラミングパラダイムやプログラミングスタイルは直交するはずだ

Eric Evansから提案されたDDDはクラスベースOOを主体とした実例が多かったわけですが、DDDという概念はOOを前提としていないと僕は捉えています。特に、ユビキタス言語、コンテキストの明示、モデリングと密接な開発といった部分は多くのソフトウェア開発において役立つと言えそうですし、おそらくはプロダクト開発全体でも言えそうです。

エンティティ、バリューオブジェクト、アグリゲート、リポジトリなどのようにEricが紹介したDDDにおける実装方法は少なくともクラスベースOOを前提とした何かだと考えられます。

データフロー図で表現できるようなアプリケーションは関数型の考え方が似合う

UNIXコマンドラインツール、PowerShell、関数型プログラミングの一部の機能、に見られるようなパイプ&フィルターパターンというのは、データフロー図で表現できるようなアプリケーションにおけるモデリングとバッチリあいます。

例えば、あるデータが入力されたら、延々とそのデータに対して変更を加えていったり、絞り込んだり、集計したりするアプリケーションです。

ひどい例かもしれませんが、「様々な人にレビューしてもらったり、判子をもらうことで、最終的に許可をもらう成果物」といったものはまさしくそうですよね。 次のような手順とかですかね。

1. 開発者がコミットした設計書
2. チーム内レビュー合格判子をもらった設計書
3. Aさんレビュー合格判子をもらった設計書
4. Bさんレビュー合格判子をもらった設計書
5. 承認会合格判子をもらった設計書
6. リリース判子をもらった設計書

このようなシンプルなデータフローとして表現できる場合にはこれがドメインモデルだと言っていいと僕は思っていて、これをDDDとして実装するなら、「よりパイプ&フィルターパターンを実装しやすい設計方法」を取るほうが楽かと思います。

実際にはもっとたくさんの条件があったり、他の作用があったりするので、それらにどう対処するかでやはりOO的にやっていくのか、モナドで何かくるんでうまいことパイプ的に見せるのかということはありそうですが、このような手順で見れるなら簡単な場合というのもあるのは確かです。

まぁ、わかっている人からしたら「それはVOとなんたらとなんたらを組み合わせたやつだよね」とか言いそうなんですけど、 僕からしたら「なら、それに名前つけたり、こういったパターンがあるって誰かに伝えたり、議論しあったほうがいいと思うよ」的な。なので、こうやって書いたわけですが。

他に考えられる例

さっきは残念な例でしたが、例えばそれぞれの一部ですが次のような例もあると考えています。

• 証券の扱い
• CIツールのようなジョブシステム
• ビルドツール

まぁ、なんらかの形でなんたらフローみたいなのに表現できて、入力にだけ着目するようなものやりやすい的な感じでしょうか。（つまり、副作用が少なめということなんだけど）

ついでに言いたかったこと

こういったことがシンタックスとして見えやすくなる可能性を秘めているF# のパイプライン演算子は素晴らしいし、みんなもF# をやろう！！！！

F#で関数型言語に触れてみよう from wof moriguchi

実践ドメイン駆動設計 (Object Oriented Selection)

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

実践 F# 関数型プログラミング入門

関数プログラミング実践入門 ──簡潔で、正しいコードを書くために (WEB+DB PRESS plus)

リスクベースドなテスト戦略を始める最初の一歩 #swtest_jp

概要

テストの戦略を考えるのは大変（手抜きしている事が多い）ですし、なんとかしたいけど、どうしたらいいかわからないという時に取れそうな手段について考えてみました。 ちなみに、テスト戦略を立て始めるのは早ければ早いほどいいです。つまり、プロジェクトスタート時から考え始めるくらいでもいい。

リスクベースドなテスト戦略

リスクベースドなテスト戦略とは、ざっくりと言うと、いろんなテストのアプローチを考えた上で、リスクの重み付けをして、優先度の高いものからうまく回避するようにテストを組み立てる。という感じです。

これにおいて僕の感覚で大雑把に「最低限テスト戦略で組み込みたいこと」は次の4つです。

• 出来る人をチームに入れる。
• データの明示的、暗黙的変換部分に着目してテストする。
• エンドユーザーが苦情を言うシーンをテストする。
• システム運用が面倒になるシーンをテストする。

逆に言うと、「なんでたかだかこれくらいのことを考慮しないでテストをやっているんですか？」と叱ることがある4つ。（もちろん、考慮した結果、必要ないと判断する事はよくありますよ。）

最初の1つ以外は順不同です。

出来る人をチームに入れる。

まず初めに考える事は、対象のプロジェクトにおいて最適な知見を持つエンジニアを探す事です。それは開発チームが埋め込みやすいバグを知っている人だったり、対象の技術について詳しい人だったり、エンドユーザーや運用について詳しい人だったり。プロジェクトのメンバーが弱い部分を補える人をチームに入れる事を考えましょう。

入れる事が難しかったら、自分たちでどうやってその部分を補えるか考えましょう。勉強すればいいのか、インタビューする事でスキルが得られるのか、テスト対象外にするか、など。

データの明示的、暗黙的部分に着目してテストする。

テストをするときにはデータの変換に着目するのが一般的です。明示的、暗黙的変換は僕が呼んでいるだけです。それぞれ次のような意味になります。

• 明示的変換 : アプリケーションのロジックとして認識して実装している変換 (ex. プロダクトコード起因)
• 暗黙的変換 : ミドルウェアやインフラによって実装している変換 (ex. HTML、RDBにおける文字列のエンコーディング)

暗黙的変換に関しては知らないとテストできないわけですが、逆に言えば「使っている技術をリストアップしてそれぞれで暗黙的変換が行われていないかを机上で確認する」というミーティングを持つだけでもテスト戦略としては有効な場面があります。

エンドユーザーが苦情を言うシーンをテストする。

「エンドユーザーに触ってほしい手順」のようなテストをすることは当然に近い物があるのですが、もっといいのはどういったときに苦情がでるかを考えてテストに組み入れる事です。 もし自分たちが使っている似ているソフトウェアがあるなら、どういったときにゲンナリしてちょっと距離を起きたくなるかを考える感じでしょうか。もしくは痛烈にTwitterとかで批判するようなことを書き込むときですかね？

システム運用が面倒になるシーンをテストする。

そのシステムを運用しているときに何をやろうとしたら面倒になるかを考えて、テストに組み入れてみます。例えば、特定ユーザーの処理だけがエラーになってしまうときにログと実際のデータをひもづけた上で正しく修正するための情報と確認をするプロセスを考えて、テストしてみるとかですね。 それが出来ないといったことになったら、あとでものすごい時間をかけることになるので。

手離れのよい開発をするためにはどうするか。といった感じでしょうか。

まとめ

いかに早くテスト戦略を立てて実行に移すかは重要だということは認識しているけれど、何から考えていいかわからない場合に考える4つの手段について記しました。リスクベースドで真っ先にでてくるこの4つは人によっては「それってレビューでする事だよね」と思われるかもしれません。まぁそれは状況によりけりなので「そうですねー」とも言えますし「作ってからじゃないとわからないこともありますよねー」もあります。

テストすべき事には「最初に決定可能な事」と「つくりながら決定可能な事」があり、後者3つの手段全てにおいて両方のテストが含まれます。どれくらいかはプロジェクトによるので、そのときの最適解を探すのがメンバーのスキル次第といったところでしょうか。

体系的ソフトウェアテスト入門

ソフトウェアテスト293の鉄則

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)

追伸 このブログを書いていて、週刊ソフトウェアテストをリリースするのわすれていました。次号で合併号として二号分の情報をのせてリリースします。（テヘッ

週刊ソフトウェアテスト 2015-8

前書き

ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容はid:kyon_mmの独断と偏見です。オススメの記事があるときや、質問などなどはコメントや@kyon_mmにご連絡くださるとうれしいです。

ハッシュタグ #swtest_jp でソフトウェアテストに関する事をツイートしてくださるととてもうれしいです！（なにかの紹介でも、議論でも、質問でも！

週刊ソフトウェアテスト 2015-7 #swtest_jp

前書き

ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容はid:kyon_mmの独断と偏見です。オススメの記事があるときや、質問などなどはコメントや@kyon_mmにご連絡くださるとうれしいです。 ハッシュタグ #swtest_jp でソフトウェアテストに関する事をツイートしてくださるととてもうれしいです！（なにかの紹介でも、議論でも、質問でも！

週刊ソフトウェアテスト 2015-6 #swtest_jp

前書き

ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容はid:kyon_mmの独断と偏見です。オススメの記事があるときや、質問などなどはコメントや@kyon_mmにご連絡くださるとうれしいです。

ハッシュタグ #swtest_jp でソフトウェアテストに関する事をツイートしてくださるととてもうれしいです！（なにかの紹介でも、議論でも、質問でも！

kyon_mmの意見

TestFairyを見ていて思ったのは、いま自分がためしにいくつか作っているツールでは「対象のソフトウェアがエラーログを出力したら、そこからテストコードの自動生成をして、CIで実行して再現したら、VCS, ITSに登録する」ということを自動化しています。（ツールを最初に実行する以外はすべてツールがやります。）つくるの難しいんですけど、もうちょっとうまくつくれたらいいなーと思いつつ、やっぱりAndroidとかだとそういったツールつくるの難しいのかなぁと思いました。

週刊ソフトウェアテスト 2015-5 #swtest_jp

前書き

ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容はid:kyon_mmの独断と偏見です。オススメの記事があるときや、質問などなどはコメントや@kyon_mmにご連絡くださるとうれしいです。 ハッシュタグ #swtest_jp でソフトウェアテストに関する事をツイートしてくださるととてもうれしいです！（なにかの紹介でも、議論でも、質問でも！

週刊ソフトウェアテスト 2015-4 #swtest_jp

前書き

ソフトウェアテストにまつわるニュースを週毎にお届けする記事です。内容はid:kyon_mmの独断と偏見です。オススメの記事があるときや、質問などなどはコメントや@kyon_mmにご連絡くださるとうれしいです。 ハッシュタグ #swtest_jp でソフトウェアテストに関する事をツイートしてくださるととてもうれしいです！（なにかの紹介でも、議論でも、質問でも！