- Transaction Script
- Active Record
- Anemic Model
- Domain Model
- 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.
- 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.
- 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
- 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
- Methods that don’t really fit on a single entity or require access to the repository belong in a domain service.
- 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.
Professional ASP.NET Design Patterns (Chapter 4)