DOAとドメインモデル貧血症

一方で、DB設計があってUIがあって、そこで初めて取次ぎ役であるクラス設計に入るというのは、これは貧血症だなんだと言われるパターンで、OOな世界でも異教徒です。

DB設計から入るから､貧血症になるということは､特に無いと思っています。ドメインモデル貧血症とは、振る舞いの無いドメインモデルに対して言われることなので。
一方､設計の進め方を業務フロー->UI->DBと進めるのは､賛成です。ユーザにとって一番大切なのは､自分がどのように業務をこなすかであり､モデルだとかDBなんてのは、副次的なものだからです。まず、自分がどのようにして業務をこなすのかということを業務フローで確認し､実際に業務で使うUIをモックで確認し､それをベースにDBを設計するというのは､ユーザの要求を理解するのに無理の無い自然な流れだと思うからです。いきなりモデルから入るのは､そのモデルが正しいということをユーザが検証できないから、現実的でないよね。
今後のモデリングは､業務フロー->UI->DB->ドメインモデルで進み､UIから導き出された業務ロジックをドメインモデルに割り当てるってのが､主流になると個人的には思っています。業務ロジックをドメインモデルに割り当てる部分をDIでやりたいんだけど､現状だとそれができないのが辛いところです。
現状だと､あきらめて、業務ロジックをドメインモデルから分離する(貧血症)かドメインモデルで直接実装する(肥満症?)のどっちかですね。
業務ロジックが簡単なものなら､貧血症でも肥満症でもどっちでも問題は無いでしょう。業務ロジックが複雑になるなら､DIを駆使できる貧血症のほうがテストがやりやすいので､良いと思います。業務ロジックを「xxxをyyyする」という風に命名し､xxxが同じやつを1つのロジッククラスにまとめれば､複雑になってもロジックが分散することは無いということは､何度かblogで書いている通りです。
ドメインモデルにメソッドを割り当てる場合には､xxxと名前が一致するエンティティにyyyのメソッドを持たせればOKです。