• Transaction Script
  • Active Record
  • Anemic Model
  • Domain Model

Transaction Script

  • Procedural style development, as opposed to object-oriented
  • Single procedure for each business transaction
  • Simple to understand
  • Easy to add functionality
  • Good for small applications
  • Does not scale in when an application grows in size or business logic.

Active Record

  • Great when underlying database model matches your business model.
  • Each business object is responsible for its own persistence and related business logic.
  • Great for simple applications
  • Entity Framework data first, Castle ActiveRecord, …
  • Bad when there is a mismatch, sometimes called an impedance mismatch, between the data model and business model.

Domain Model

  • A conceptual layer that represents the domain being worked in.
  • Things exist in this model and have relationships with other things in the model.
  • The things have data and behavior.
  • The closer the domain model represents the real domain the better.
  • The difference between DM and AR is the business entities have no knowledge of how to persist themselves.
  • There doesn’t necessarily need to be a one-to-one mapping between the data model and the business model
  • A domain model closely models the real domains workflow
  • It can easily be unit tested because it is decoupoled from the repository layer, unlike the Active Record model
  • More complex than Active Model, can be overkill on small applications

Anemic Domain Model

  • Sometimes referred as an anti-pattern
  • Behavior is not contained withing the domain objects, and is instead found out of the model.
  • Violates the “Tell, Don’t Ask” principle.

Domain-Driven Design (DDD)

  • Useful when dealing with complex business logic
  • Models the real domain by fully understanding it and placing all the terminology, rules, and logic into an abstract representation within your code.

Aspects of DDD

The Ubiquitous Language

  • Common vocabulary used across the organization to describe the domain.
  • Domain expert is someone with the knowledge and skills in a particular domain who works closely to help build domain model.
  • Class names, methods, and properties should be based on this language.


  • Entities are the “things” of a domain
  • Have an identity

Value Objects

  • Have no identity
  • They are of value because of their attributes only

Aggregates and Aggregate Roots

  • Groups of objects
  • Treated as a unit for purposes of data changes
  • An aggregate root is a special entity that acts as the logic way into an aggregate

Domain Services

  • Methods that don’t really fit on a single entity or require access to the repository belong in a domain service.

Application Services

  • Sits above the domain model and coordinates activity


  • Abstracts away data access


  • Helps enforce the separation of concerns.


Persistence Ignorance (PI)

Plain old common run-time object (POCO)

View models – flattened views of domain model used solely for displaying of data.

Value object

Test-Doer pattern


Professional ASP.NET Design Patterns (Chapter 4)