Domain Logic describe the functional
algorithms or business logic that handle the
information exchange between a database and
a user interfaces.
A well organized Domain Logic components
are easy to maintain and scale.
A Service Layer is placed over an underlying
Domain Model or Table Module
Transaction Script organizes business logic by
procedures where each procedure handles a
single request from the presentation.
A Transaction Script organizes all this logic
primarily as a single procedure, making calls
directly to the database or through a thin
Each transaction will have its own Transaction
Script, although common subtasks can be
broken into sub procedures.
With Transaction Script the domain logic is
primarily organized by the transactions that you
carry out with the system.
For e.g.: If your need is to book a hotel room,
the logic to check room availability, calculate
rates, a the database is found inside the Book
Hotel Room procedure
It is independent of other transaction.
It allow you to manipulate instances of scripts
as objects at runtime.
When to use it…?
Glory of Transaction Script is its simplicity .
As the business logic gets more complicated
,we can move to the Domain Model.
Domain Model is an object model of the
domain that incorporates both behavior
More complex business domains need to build in
It will give you many more options in structuring the
code, increasing readability and decreasing
Domain Model mingles data and process, has
multivalued attributes and a complex web of
associations, and uses inheritance.
Simple Domain Model
looks very much like the database design with
mostly one domain object for each database table.
use Active Record
Rich Domain Model
look different from the database design, with
inheritance, strategies, and other patterns, and
complex webs of small interconnected objects.
requires Data Mapper
If you have complicated and ever changing business rules
involving validation, calculations, and derivations,
chances are that you'll want an object model to handle
Data Mapper which helps keep your Domain Model
independent from the database and is the best approach
to handle cases where the Domain Model and database
One of the problems with Domain Model is
the interface with relational databases.
If you have many orders, a Domain Mode
will have one order object per order.
To overcome such problems we move to Table
Table Module is a single instance that
handles the business logic for all rows in
a database table or view.
A Table Module organizes domain logic with
one class per table in the database and a single
instance of a class contains the various
procedures that will act on the data.
Table Module will have one object to handle
The strength of the of Table Module is that it allows
you to package the data and behavior together and at
the same time play to the strengths of the relational
We use Table Module with a backing data structure
that's table oriented.
The tabular data is normally the result of SQL call
and is held in a Record Set that mimics a SQL table .
Grouping the behavior with the table gives you many
of the benefits of encapsulation.
The Table Module may be an instance or it may be a
collection of static methods.
The Table Module may include queries as factory
Table Module is very much based on table-oriented
data ,so we can use it when we access tabular data
using Record Set .
Table Module allows you to fit business logic into the
application in a well-organized manner, without
losing the way the various elements work on the
Service Layer defines an application's boundary with
a layer of services that establishes a set of available
operations and coordinates the application's response
in each operation.
It encapsulates the application's business
logic, controlling transactions and coordinating
responses in the implementation of its operations
Service Layer is a pattern for organizing business
Service Layer factors each kind of business logic into
a separate layer, yielding the usual benefits of
layering and rendering the pure domain object classes
more reusable from application to application.
Service Layer is implemented as a set of thin facades
over a Domain Model
The classes implementing the facades don't
implement any business logic but the Domain Model
implements all the business logics
The thin facades establish a boundary and set of
operation through which client layers interact with
the application, exhibiting the defining characteristics
of Service Layer.
Service Layer is implemented as a set of thicker
classes that directly implement application logic but
delegate to encapsulated domain object classes for
A Service Layer is comprised of these application
service classes, which should extend a Layer
Supertype , abstracting their responsibilities and
Service Layer classes are well remote invocation
from an interface granularity perspective.
Starting with a locally invocable Service Layer
whose method signatures deal in domain object, we
can add services remotability when we need it by
putting Remote Facades on your Service Layer .
Identifying the operations needed on a Service Layer
boundary is pretty straightforward and they're
determined by the needs of Service Layer clients.
The starting point for identifying Service Layer
operations is the use case model and the user
interface design for the application.
The benefit of Service Layer is that it defines a
common set of application operations available to
many kinds of clients.
An application with more than one kind of type of its
business logic, and complex response in its use cases
involving multiple transaction resources, it makes a
lot of sense to include a Service Layer with container-
managed, transactions, even in an undistributed
Domain Model you may want to consider Service
Layer to give your Domain Model a more distinct
Patterns of Enterprise Application Architecture,
Martin Fowler, Addison-Wesley Professional,
2003,ISBN-10: 0321127420 ISBN-13:
Paper :Homework 1 : Domain Logic , by Basanta Raj
Onta (111701), Computer Science – August 2010.