Understand Design Patterns

Architectural and design patterns are gaining increasing attention in the .NET programming community (see Additional Resources). MSDN dedicates a section to architectural and design topics. The "Enterprise Solution Patterns: Services Patterns" document on MSDN introduces well-known software patterns and provides usage guidelines and C# samples. Martin Fowler's book, Patterns of Enterprise Application Architecture, is a must-read for .NET enterprise-solutions developers, even though most of its code samples are in Java.

All enterprise business solutions are based on a central, high-level architectural pattern called the Three Layered Application pattern. This pattern splits an application into a presentation layer, a business-logic layer, and a data-access layer. Pattern experts agree about most of the issues—and the possible design and implementation solutions—for the presentation and data-access layers. However, there are multiple approaches to the business-logic layer—not surprisingly, because this layer becomes complicated quickly in all but the simplest applications.

Fowler, Rockford Lhotka, and Jimmy Nilsson take a standard object-oriented approach—known as the domain model—which defines business objects that encapsulate both data and class behavior. The term behavior means both data validation and actions and processes the object can execute, sometimes in coordination with other business objects.

The classic domain model is great for create, retrieve, update, and delete (CRUD) intensive applications in which application use consists mostly of "get the data," "let the user edit data," and "save the data." A pure domain model faces some issues when dealing with heavily service- and process-driven applications. Several processes (or use cases) typically require the coordination of several business entities.

Others prefer to separate the business layer into an application layer (also known as a process, workflow, or fa├žade layer) and a domain layer, in order to split business objects and business processes apart. They put use-case-based business-process activities in the application layer, and they put business entities (lightweight business objects) in the domain layer.

Data encapsulation and intrinsic validation still hold in business entities, but most of the behavior moves to the application layer. (A strict approach requires that all the behavior move.) Service Oriented Architecture (SOA) proposes a further decoupling of data from behavior and looks at applications from the point of view of the "services" they provide. The service-based approach is biased toward the Web services initiative, and it actually represents a service layer on top of an existing business layer (whatever it is), rather than a replacement.

However, a SOA-"compliant" application arguably fits better with an application/domain-layer architecture. The use-case-based application layer is quite close semantically to the service layer, so that most issues the service layer must deal with involve only data mapping required for interoperability issues.

The SOA architecture the Microsoft document proposes splits the domain layer further into business objects and business entities. Business entities are simply data containers. Business objects constrain the business rules that apply to business entities. (This kind of layering is by no means the "official and unique" Microsoft architecture proposal.)