この辺の話に関連して。
http://www.liris.org/blog/662865e5306f-cms-blog-exchange1
http://takanory.net/takalog/429/
RDBMSのテーブルなどだと，正規化とか設計のセオリーがあるのだけど，ZODBがバックエンドなZopeの場合オブジェクトの構造を設計するためのセオリーはあまり見かけない。それだけ難しいってことだと思う。関連する要素が複雑だからね。
とりあえず，私が構造設計の指針にしていることをルール化して書いてみます。
オブジェクトにすべきものとすべきでないもの
Zope/CMF/Ploneのオブジェクトは，RDBMSの列などに比べて粒度が大きいので，オブジェクトにするかしないかについてはよく考える必要がある。余計なものまでオブジェクトにすると，データ領域にかけるオーバーヘッドが大きいし，セキュリティ上のリスクも増す。
独自にViewを持つとか，独自に公開の操作method(setter,getter意外にもたくさん)のセットを持つ場合はオブジェクトとして分離すべき。それ以外であればスキーマとかアトリビュートで表現すべき。粒度でいうとスキーマ >>>> アトリビュートなので，設定用のインターフェースを持たせる必要がなければアトリビュートにすべき。
コンテナにすべきものとすべきでないもの
コンテナというのは，フォルダのように内部に別のオブジェクトを持つことができるオブジェクトのことね。一般的なオブジェクトに対してコンテナはより粒度が大きいし，オブジェクトのトラバースにパフォーマンスを要求する。コンテナにする必要がないものはしないほうがいい。また，大量のオブジェクトを収納する可能性のあるコンテナはBTreeFolder由来であるべき。ただし，粒度は増すからなんでもBTreeFolderを継承しない方がいい。
コンテナにする場合，内部のオブジェクトがかならず「下位」に置かれる点についても留意すべき。下位オブジェクトは上位コンテナのセキュリティ設定の影響をうけるし，一緒に消されちゃう。たとえばBlogのコメントは，エントリと関係なく参照されることもありえるので，下位には置かない方がいい，という考えも成り立つかと思います。
RDBMSでいうところの「第三正規化」をするようなデータ構造をオブジェクトで表現する場合には，たぶんコンテナにしないでリファレンスとかアトリビュートで管理した方がいいと思う。Cとかの構造体なら，ポインタのリストで管理するようなデータ構造。
自分だけが使うものを富豪的に「なんでもコンテナ」とするのはアリ。でも，広く配布するプロダクトの設計がナニだったりすると，ちょっと。。。「第三正規化」が感覚的に分からない人，というのは人口中一定数いるはずなので，そういう人はこういう議論も理解できないのかも知れない。設計は「やるべき立場にある人がやる」のが正解だと思います。
