Service Design Principles: Facade Pattern, DTO, and Service Interface Guidelines

In the process of designing a service center, careful planning of service interfaces and data models is essential for scalability; the author recommends studying Domain‑Driven Design by Eric Evans and SOA Principles of Service Design by Thomas Erl as foundational references.

Facade (外观) Pattern : The Facade pattern decouples front‑end applications from the internal modules of the service center, providing loose coupling, simplicity, and clearer access layers. Its advantages are listed and illustrated with a diagram.

DTO Usage : Data Transfer Objects hide complex or volatile internal data structures from front‑end applications, improving stability. The article shows how DTOs simplify data exchange and reduce redundancy, accompanied by a diagram.

Service Interface Design Principles :

Contract‑first: Define clear service contracts involving business, product, and technical stakeholders before implementation.

Service cohesion: Group related operations together and ensure each service provides all logic needed for its domain.

Coarse‑grained services: Design operations that represent complete business use cases to reduce remote calls and coupling.

Eliminate redundant data: Avoid transmitting unnecessary fields to reduce serialization overhead.

General contracts: Use widely supported data types to ensure cross‑language and cross‑platform compatibility.

Isolation of change: Prevent internal model changes from affecting front‑end applications, using Facade and DTO as buffers.

Contract wrapping: Introduce a delegate service on the consumer side to shield it from contract changes.

Statelessness: Design services without reliance on previous interactions to improve scalability and reliability.

Service naming: Prefer business‑oriented nouns for services and verbs for operations to enhance usability.

Operation design: Use specific business meanings and appropriate parameter granularity (coarse vs. fine) to simplify versioning.

Important services should not depend on non‑important services, respecting hierarchical dependency rules.

Code examples illustrate the principles:

ClaimEntryService {
    createClaim(String userId);
    ClaimItemDetails[] getClaimItems(int );
    ClaimErrors[] validateClaim(int claimId);
    void removeClaimItem(int claimId, int itemId);
    int addClaimItem(int claimId, ClaimItemDetails details)
    int submitClaim(int claimId);
}

ClaimApprovalService {
    int approveClaimItem(int claimId, int itemId, String comment);
    void approveClaim(claimId)
    void returnClaim(claimId)
    ClaimItemDetails[] getClaimItems(int );
    ClaimErrors[] validateClaim(int claimId);
}

ClaimPaymentService {
    void payClaim(int claimId);
}

Additional snippets demonstrate DTO conversion, service delegation, and method signatures for creating customers with fine‑grained versus coarse‑grained parameters.

//ArticlesService is a consumer‑defined interface
class ArticlesServiceDelegate implements ArticlesService {
    //auto‑generated stub
    private ArticleFacadeStub stub;

    public void deleteArticles(List
ids) {
        stub.deleteArticles(ids);
    }
}

The article concludes that while many principles exist, simplicity is key; designers should apply the appropriate rules based on business understanding and continuously refine their approach.