Replacing Custom DAO Code With Web Service Calls

Question

In most of our webapps, we use a three-tier architecture: Controllers/ViewHelpers, Service, and DAO layers. However, some of these items a pretty much boilerplate code. Case in point: most apps database schemas have their own Department table (call it T_DEPARTMENT), and on the code side this requires a Model Class for Department, a DepartmentDAO class, etc.

What I would LIKE to do is create a common schema for all departments that all apps would access (yes, that should already be the case, but it's not...). Then I'd like to slap a simple web service on the app server whose only job is to access that common table. Instead of custom DAO code, dedicated model object, etc, the information would simply be retrieved by the webservice call, probably in JSON format.

However... I need to know the answers to some questions:

1. Is this really a cost effective idea? We probably do about 10 small-to-medium projects for each of our company's fiscal year (new or rewrites of legacy apps).
2. If the DepartmentDAO mostly consists of Save(), Delete(), and FindByName()/FindById() methods, would the amount of code/effort be significantly reduced by replacing it with web service code? (Note that there have to be code written to do things like convert JSON results to select boxes, etc)
3. Would the security implications of web service calls be a nightmare?

In short, is this worth it in terms of manpower costs/maintainability/etc?

Answer 1

Creating a common schema for all systems is often not realistic.

It maybe OK as you are developing, but the cost of making changes will eventualy be so high that it is not possible to make any changes.

The pattern for a solution for this is "Bounded Context", there is a good description of this in Eric Evan's Domain Driven Design book