- Transaction script
- Domain model
- Table module
Consider the example below:
A company sells three products: A, B, and C, along with some support for using these products. If a client buys product A, the company receives all of the revenue upfront. If the client buys product B, the company receives one third of the revenue now, one third in 60 days, and one third in 90 days. If the client buys product C, the company receives one third of the revenue now, one third in 30 days, and one third in 60 days.
A script for an action, or business transaction; The driving force is still that of a procedure for each action.
Transaction Script Pattern follows a procedural style of development rather than Object Oriented Programming approach.
- Transaction Boundaries: 事物的开始和结束都很明确
- Scalability: 随着业务逻辑变得越来越复杂，维护良好设计变得越来越困难
- Duplication: 代码重复量大，每一种不同的事物都有专门的代码，即使它们很相似也是如此
An object model of the domain that incorporates both behaviour and data.
The domain model pattern involves constructing a model of the business domain of the system, usually an object-oriented model, and then coupling the behaviour to the objects in the domain using methods.
- Extensibility: to add more behaviour, one only need to add the classes/objects to the domain model
- Managing comain complexity
- Need experience
The table module pattern attempts to blend the transaction pattern and domain model patterns. A single instance that handles the business logic for all rows in a database table or view.
On the surface Table Module looks much like a regular object. The key difference is that it has no notion of an identity for the objects it’s working with.
- Less duplication: behaviour is tied to the concepts/classes
- Scalability: 同Transaction Script
- Extensibility: 同Transaction Script
A Service Layer is placed over an underlying Domain Model or Table Module. A domain layer that uses only Transaction Script isn’t complex enough to warrant a separate layer.