●分割するルールがはっきりしない
理屈の上ではDAOやサービスは、どのようなクラス構成でも良いのです。（中略） しかし、これは明確な基準というより、単なる目安に過ぎないものです。
●インターフェースがバラバラになりがち
分割する単位があいまいであるということは、どこにどんな機能があるかもあいまいになります。
●機能の共通化がしにくい
サービス・DAOは「抽象的なモデル」であるというよりは、 「具体的な処理」の集まりに過ぎないからです（だから、分割するルールがはっきりしない）。
●リソース層がボイラーテンプレートになる
リソース層は、HTTPの世界と、プログラムの世界をつなぐだけの、ボイラーテンプレートになってしまうのです。本当は、そんなものは自動生成するべきなのです。
●何かやった気になる
「サービス層」「DAO層」はかなり大雑把な分割方法なのですが、 その割に、「MVCパターン」「ビジネスロジックとWEBロジックの分離」に従った実装をしている気になりがちです。
確かに一理ある。
とはいえ、これはつまりRoRやCakePHPのようなCoC的なF/Wの方が優位だという話だと思うけど、現実にはそれらのF/Wのお作法に則った泥団子が量産されている現実を鑑みると素直に同意できないというか。やっぱダメだったんじゃねぇの？ という思いが否めない。
システムがある程度の規模を超えるとやっぱりレイヤーは厳密に分離されていた方が何かと手を入れやすいという現実から、ヘキサゴナルアーキテクチャを意識した構成に寄っていくので、そういう時は各レイヤーがシームレスに統合されたF/Wは逆にイレギュラーなことをしなきゃならんのでクソ面倒だったりする。
CoC的なF/Wはプロトタイプや小規模かつ単純なCRUDアプリの作成には最適だけど、ある程度以上の規模になると結局はアーキテクチャの再検討が発生するので効率が悪くなるイメージ。