Common domain logic must be made available to a number of web services that may have different API styles or Client/Service Interaction Styles.
How can web services reuse common domain logic without duplicating code?
Web services may be implemented as Transaction Scripts that contain all of the data validation, calculations, database, and file access logic required to process a client's request. Unfortunately, this logic can become quite complex and lengthy, and may also be duplicated across a number of web services. This inevitably leads to maintenance issues. Service developers can increase the readability of service code by extracting select code fragments out of the web service into smaller methods. However, the problem of duplicated code is not mitigated if these extracted methods are placed into the same class as the web service method.
Encapsulate common business logic in domain layer entities that exist outside of the web service. Limit the logic within web services to algorithms that direct the activities of these entities.
Operation Scripts contain application logic consisting of conditional, iteration (i.e. looping), and sequencing statements. However, the bulk of the domain logic resides in external Domain Layer entities (e.g. Domain Models, Table Modules). Web services that are implemented as Operation Scripts inspect each request to determine which domain layer entities should be used, and often function as the top-most transaction manager for the entities that are used to fulfill the client's request. This pattern was first described by Randy Stafford in the Service Layer pattern.