Mastering Responsibility-Driven Design: How GRASP Shapes Low Coupling & High Cohesion

Why Use Responsibility‑Driven Design (RDD)?

Software is inherently complex; beyond functional requirements it must address non‑functional concerns like security, scalability, and maintainability. RDD treats software objects as having responsibilities, mirroring human division of labor, which makes systems easier to understand and manage, especially in micro‑service architectures.

Assigning Responsibilities

Responsibility assignment starts with clear descriptions of duties. Domain models define object attributes, while use‑case models define behaviors (methods). The GRASP (General Responsibility Assignment Software Patterns) framework provides nine named patterns that guide this assignment.

Key GRASP Principles

Prevent Variation – Identify unstable aspects and create stable interfaces to isolate change.

Low Coupling, High Cohesion – Reduce dependencies and keep related responsibilities together to improve maintainability and reusability.

Creator – Assign object‑creation responsibility to a class that contains or aggregates the created object.

Information Expert – Give a responsibility to the class that has the necessary information.

Pure Fabrication – Introduce artificial classes to hold highly cohesive responsibilities that don’t map directly to domain concepts.

Controller – Provide a unified entry point to handle system events.

Polymorphism – Use polymorphic operations to handle variations without conditional logic.

Indirection – Insert mediator objects to avoid direct coupling.

Coupling and Cohesion Details

Coupling measures the degree of inter‑dependence between elements, while cohesion measures how closely related the responsibilities of a single element are. High coupling leads to ripple effects during changes; low coupling and high cohesion improve stability, extensibility, and reuse.

Types of coupling (from strongest to weakest) include content, shared, common, control, data, and non‑direct coupling. Strategies to reduce undesirable coupling involve using single‑direction dependencies, minimizing dependency chains, and preferring data coupling.

Practical Cases

Case 1: Replacing JPA with MyBatis

@Component
public class CloseOrderService {
    @Autowired(required = false)
    @Qualifier("rstOrderTransactionManager")
    JpaTransactionManager tm;

    public void invalid_order(Long orderId, Long userId, Short processGroup)
            throws UserException, SystemException, UnknownException {
        // ... other logic omitted
        DefaultTransactionDefinition def = new DefaultTransactionDefinition();
        TransactionStatus ts = tm.getTransaction(def);
        try {
            order = orderDAO.get(orderId);
            order.setStatusCode(toStatus);
            order.setUpdatedAt(new Timestamp(System.currentTimeMillis()));
            orderDAO.save(order);
            tm.commit(ts);
        } catch (Exception e) {
            if (!ts.isCompleted()) {
                tm.rollback(ts);
            }
            if (e instanceof SatisfiedStateException) {
                return;
            }
            throw e;
        }
    }

    @Transactional(transactionManager = "rstOrderTransactionManager", rollbackFor = Exception.class)
    public void invalidOrder() {}
}

@Component
public interface OrderDAO extends JpaRepository<OrderPO, Long> {
    @Query(value = "sql语句", nativeQuery = true)
    Long generateGlobalOrderId(@Param("userId") Long userId,
                               @Param("restaurantId") Long restaurantId,
                               @Param("seqName") String seqName);
}

The migration impacts over 70 classes and transaction handling, violating low‑coupling principles; applying polymorphism can mitigate the impact.

Case 2: Who Should Create the Payment Order? Analysis of an e‑commerce system shows that the order service, not the BOS service, should own payment‑order creation to keep responsibilities aligned and avoid unnecessary coupling.

Architectural Patterns Supporting GRASP

Layered architecture and Hexagonal (Ports & Adapters) architecture help enforce separation of concerns, low coupling, and high cohesion across system boundaries.

Diagram summarizing GRASP principles and their relationships to other design patterns.

Illustration of low coupling vs. high cohesion.

Example of order‑goods relationship and responsibility distribution.