FREE hit counter and Internet traffic statistics from freestats.com

Sunday, November 14, 2004

Organizing Domain Logic

There are many different ways of organizing domain logic in Business Components that encapsulate calculations, validations, and other logic that drives the central functionality of an application or service. One of the books I like as a software architect is Patterns of Enterprise Application Architecture by Martin Fowler. In that book Fowler defines three architectural patterns (here listed in increasing order of complexity) that designers use to organize domain logic. I’ll explore each of these patterns as they apply to .NET development in a series of upcoming articles.

  • Transaction Script. This pattern involves creating methods in one or a few Business Components (classes) that map directly to the functionality that the application requires. The body of each method then executes the logic, often starting a transaction at the beginning and committing it at the end (hence the name). This technique is often the most intuitive but is not as flexible as other techniques and does not lead to code reuse. This pattern tends to view the application as a series of transactions.
  • Table Module. This pattern involves creating a Business Component for each major entity used in the system or service and creating methods to perform logic on one or more records of data. This pattern takes advantage of the ADO.NET DataSet and is a good mid-way point between the other two. This pattern tends to view the application as sets of tabular data.
  • Domain Model. Like the Table Module, this pattern involves creating objects to represent each of the entities in a system, however, here each object represents one Business Entity rather than only having one object for all entities. Here also, the logic for any particular operation is split across the objects rather than being contained in a single method. This is a more fully object-oriented approach and relies on creating custom classes. This pattern tends to view the application as a set of interrelated objects.

In additon to these patterns I'll also look at how the Service Layer pattern interacts with these. Should be fun.


No comments: