もしくーすがOOAなのかER分析なのかしったこっちゃないというなら俺は興味ないな。
システムの狭い世界での話であっても、OOAと構造化には明らかな壁があるのに
OOPLを導入してもその壁をうまく越えられてない人が結構いる。
くーすでクラス図もなしにバウンダリを基準に設計する(と読めたけど違う?)ものなら
壁を越えられない人たち向けには良い指針になるかもしれない。

前に使ったある外注は顧客クラスがあるにもかかわらず、
パスワード変更クラスとメールアドレス変更クラスをつくりやがった。
OOAでの1クラスが、複数のバウンダリに登場するのでバウンダリ基準はいくないと思う。

あと顧客が納得できるモノは画面イメージだけっていうのには諸手を挙げて賛同するけど、
顧客が仕様変更したがるのも画面なわけで、「やっぱり確認画面をいれたい」みたいな
変更要望に強くするためには、その後ろにあるクラス設計がいかに業務にマッチしているかが
重要になってくると思うんだけどお前らはどう思い松か？