2ch

http://d.hatena.ne.jp/higayasuo/20041220#1103529853
>話を簡単にするために常にデータと振る舞いを一緒にするというのは、
>それはそれでOK。
>
>ただし、機能が増えるにしたがって役割多すぎなクラスになる
>危険性があるということです。最初は、データと構造を一緒に
>しておいて、機能が増えてきたらリファクタリングすればいい
>という考えもあるかもしれません。しかし、それは、
>リファクタリングではありません。利用する側から見て
>インターフェースが変わってしまうからです。

インターフェース/クラスの内部でExtract Classしたクラスへ対して委譲すればいいだけは?
そうすればインターフェースは変わりませんよね。

それはそうですが、ドメインモデルの中身が、役割分割したクラスに委譲しているだけなら、ドメインモデルは、表面的なものになってしまう気がします。

http://d.hatena.ne.jp/higayasuo/20041220#1103529853
>「データ構造を公開することによる疎結合性を妨害」という点では、
>永続化されるようなデータの構造は、もともとpublicですから特に
>問題にはならないと思います。

何に対してpublicなのでしょうか?

また、データ構造をクラスの外へ公開することによるデメリットとして、修正箇所がアプリケーション中に分散してしまうことなどがあると思いますが、publicであることはこのことに何か解決策をもたらしているのでしょうか?

もともと永続化されるデータ、テーブルで管理されるようなデータというのは、その構造は、ER図などで外部に対して公開されています。
一般的に言われるようなカプセル化の話は当てはまりません。