Services, DAOs and Functional Organization

2008 January 29
by Paul Marcotte
While cleaning out the office recently, I ran across a couple of textbooks I kept from my business school courses. I didn't care much for business school, but I did learn some valuable concepts. A few of which came from a course on Organizational Behaviour (OB). OB is a "management science" which can be briefly described as the study of groups in organizations. A goal of OB is to determine the best strategy to use within an organization to maximize employee performance (productivity) and, as a result, profitability. If you think of an organization with managers and employees, where each employee performs specific duties, you might find it strange to have a manager for every employee. You rarely see this in the real world, because it is grossly inefficient.Let's pretend for a moment that we have an application for a fictitious Accounting department, where Services are managers and Data Access Objects (DAOs) are subordinates. For this example, our DAOs are filing clerks, who's sole duty is to file and retrieve records of a particular type (Orders, LineItems, Invoices and Payments). In our application, Orders have 1..n LineItems, 1..n Invoices and Invoices have 0..n payments. Here's an example of how you could set up your application. When each DAO has a Service, we end up with a vertical or 'silo' approach to our application. A major drawback to this approach is that the coordinated effort required to produce an Order, or Invoice document requires that multiple Services communicate in order to achieve the desired result. And, in the case of the Invoice and Order Services, we have a bi-directional relationship that represents a circular reference. If we change the Accounting depart to have a single Service and increased the Service's span of control over subordinates, we can coordinate the DAOs effort without the inter-service communication dependencies. This is a lot closer to what you would see in a real world Account department. One manager for several clerks. An immediate benefit of this design, is that it allows you to control saving composed objects as transaction without having to manage that transaction across services. When I first started with object-oriented programming in ColdFusion, I quickly found productivity gains by using a code generation tool. Brian Rinaldi's Illudium is a great tool for generating anything from cfcs to configuration files from database introspection. While this is a boon, it can also be a trap if you don't use the tool wisely. On many occasions, Brian has made it clear that Illudium is a productivity tool, not an application modeler. I still use Illudium to generate code, but I always re-organize the code in a way that helps achieve both a smaller code base and more functionally organized application.