Are software architects not working hand-in-hand with developers?

Some time ago, a project I participated as a team manager, called my attention. The development team was constantly complaining about the complexity they had to grapple with for implementing every single use case. When asked whether their difficulty lay in the technological aspects, or even if the core business involved was too complex, they reported that their problem was elsewhere. Namely the challenge actually had to do with the steps they had to follow in order to attain, for instance, a simple CRUD respecting the architecture designed by the software architect. A CRUD with just two attributes required the development of 10 different classes to allow the insertion of a simple record in the database.

Then I coincidentally came across a blog posted by Okke van ‘t Verlaat which got me thinking about our predicament.

Our J2EE based project demanded that the development of any CRUD follow a bundle of classes defined through several design patterns, as follows:

Diagram

The team made use of this set of classes in about 90% of the use cases they implement. This structure was designed using a Business Delegate, a Session Façade, Application Service(s), Data Transfer Object(s), EntityBean(Simple data Pojo) and Data Access Object. Moreover, it was always necessary to use factory embedded abstract classes for the DAO´s, Business Delegate and Application Service.

The diagram above shows HibernateDAO realizing Interfaces (DAO's). It is important to remind that Hibernate provides database independence for several vendors (in this project we need to be able to work with different databases). As a matter of fact, is it really necessary to create interface for DAO's?

This architecture represents a possible anemic domain model, and it was built from several design patterns that aren’t necessary. There aren't business objects with domain logic, which are responsible to keep track of the business rules. Instead of it, there are services objects that catch the domain problem.

This services objects are using business objects only to storage data. Is it "organized" as procedural design style? They are keeping business operations into service objects in the project as a whole.

I agree that it is important to have a service layer that encapsulates the application logic, helping transaction and managing information of operations. Therefore, does this choice avoid the creation of core business objects? With this architecture, a simple insert required the implementation of several classes. Isn’t it possible to throw some of these classes away?

Why the software architect don't think simple when designing the architecture (KISS - Keep it simple as possible)?

It is fundamental for software architect to provide a solution design that is truly viable and that can be successfully and rapidly constructed, implemented, operated and managed.