Showing posts with label Domain Logic. Show all posts

Saturday, 24 August 2013

Domain Logic Patterns

🚀 Master Enterprise Architecture & Design Patterns!

Subscribe to Ram N Java for straightforward, beginner-friendly software development tutorials!

Understanding Domain Logic Patterns

In enterprise application development, domain logic—often called business logic—represents the core business rules, calculations, and validations of your system. Organizing this logic cleanly is crucial for maintaining maintainable and scalable code.

As documented in Martin Fowler's classic work Patterns of Enterprise Application Architecture (PofEAA), there are four foundational domain logic patterns you should know.

The 4 Core Domain Logic Patterns

1. Transaction Script Pattern:
Organizes business logic by procedures where each procedure handles a single request from the presentation layer. Ideal for simpler applications with straightforward workflows.
2. Domain Model Pattern:
An object-oriented approach where network objects incorporate both behavior and data. This pattern shines when handling complex, interconnected, and evolving business rules.
3. Table Module Pattern:
A single instance that handles the business logic for all rows in a database table or view. It provides a tabular structure to represent business logic while keeping it tightly aligned with relational tables.
4. Service Layer Pattern:
Defines an application's boundary with a layer of services that coordinates response operations and encapsulates business logic execution across domain models.

How to Choose the Right Pattern?

Choosing the right pattern depends largely on your domain complexity:

For applications with minimal business logic, a Transaction Script gets the job done quickly with low overhead.
When dealing with database-centric schemas with tabular data, a Table Module offers natural structure.
For complex domain problems with deep validation rules, inheritance, and rich relationships, a Domain Model backed by a Service Layer offers unmatched long-term maintainability.

What is the Service Layer Design Pattern?

The Service Layer Pattern is a core domain logic pattern from Martin Fowler’s classic book Patterns of Enterprise Application Architecture (PofEAA).

In enterprise systems: A Service Layer defines an application's boundary with a set of available operations and coordinates the application's response in each operation.

It acts as the central entry point between the presentation/client layer and the underlying domain and data access logic.

Real-World Example: Employee Payroll Processing

Imagine an enterprise HR application. Clients need to perform business tasks such as calculating monthly salary or calculating leave balances:

Client Call: The client triggers an action, such as calculateMonthlySalary().
Service Boundary: The Service Layer exposes this method and receives the request.
Business Coordination: The Service Layer coordinates domain classes and data access layers to execute database queries, apply tax rules, and compute pay.
Result Dispatch: The Service Layer returns the clean, processed result back to the presentation layer without leaking database internals.

Key Responsibilities of the Service Layer

Defines Application Boundaries: Establishes clear API boundaries separating clients from internal business objects.
Coordinates Transactions: Controls workflow flow, security checks, and transaction boundaries across domain models.
Client Abstraction: Internal clients can invoke services directly, while external clients can interact cleanly through a Facade or service packet.

What is the Table Module Design Pattern?

The Table Module Pattern is an enterprise domain logic pattern from Martin Fowler’s Patterns of Enterprise Application Architecture (PofEAA).

In simple terms: A Table Module organizes domain logic with one class per database table or view, where a single instance of that class contains all the procedures and business rules that act on the table's data.

Real-World Example: Hotel Room Reservation System

Consider a database schema for booking hotel rooms with three primary tables:

Hotel Table: Stores hotel records (e.g., hotel_id, hotel_name).
Room Table: Stores room records (e.g., room_id, room_number, number_of_beds).
Booking Table: Stores booking records (e.g., booking_id, hotel_id, room_id, is_booked).

Under the Table Module pattern, you define one dedicated module class for each database table:

Hotel Module Class: Handles all queries, updates, insertions, and business logic for all rows in the Hotel table.
Room Module Class: Handles room availability checks, updates, and modifications across the entire Room table.
Booking Module Class: Encapsulates booking reservations, room assignment checks, and cancellations across the Booking table.

Key Characteristics & When to Use

One Class Per Table: Maps business logic directly to table schemas instead of creating individual entity instances per row.
Record Set Integration: Pairs naturally with tabular data structures such as Record Sets or DataSets.
No Inheritance Support: Unlike rich Domain Models, Table Modules do not support object-oriented inheritance relationships.
Best Suited For: Applications where business logic is moderately simple and structured strictly around relational tables.

What is the Transaction Script Design Pattern?

The Transaction Script Pattern is one of the most fundamental domain logic patterns introduced in Martin Fowler’s Patterns of Enterprise Application Architecture (PofEAA).

In simple terms: A Transaction Script organizes business logic into procedures where each procedure handles a single request from the presentation tier.

Real-World Example: Booking a Hotel Room

Imagine a client visiting your website to book hotel room number 142. Using the Transaction Script pattern, you write a single procedure—let's call it bookHotelRoom()—that executes the entire business transaction from start to finish:

Step 1 (Check Availability): Query the database to verify if room 142 is vacant for the chosen dates.
Step 2 (Price Calculation): Compute the total booking fee, including taxes and discounts.
Step 3 (Payment Processing): Accept payment from the client.
Step 4 (Database Update): Mark room 142 as booked in the database.
Step 5 (Commit Transaction): Commit the database transaction so the reservation is permanently saved.

Key Advantages of Transaction Script

Simplicity: It is straightforward to understand and implement without needing complex object models.
Low Overhead: Perfect for small applications or applications where business logic is mostly CRUD operations.
Direct Database Access: Plays well with thin database wrappers like Table Data Gateway or Row Data Gateway.

Saturday, 24 August 2013

Domain Logic Patterns

🚀 Master Enterprise Architecture & Design Patterns!

Understanding Domain Logic Patterns

The 4 Core Domain Logic Patterns

How to Choose the Right Pattern?

Recommended Design Pattern Tutorials:

Service Layer Design Pattern

🚀 Master Enterprise Java & Software Architecture!

What is the Service Layer Design Pattern?

Real-World Example: Employee Payroll Processing

Key Responsibilities of the Service Layer

Recommended Design Pattern Tutorials:

Table Module Design Pattern

🚀 Master Enterprise Java & Architecture Patterns!

What is the Table Module Design Pattern?

Real-World Example: Hotel Room Reservation System

Key Characteristics & When to Use

Recommended Design Pattern Tutorials:

Transaction Script Design Pattern

🚀 Master Enterprise Java & Architecture Patterns!

What is the Transaction Script Design Pattern?

Real-World Example: Booking a Hotel Room

Key Advantages of Transaction Script

Recommended Design Pattern Tutorials:

Tutorials