Core Software Architecture Principles and Design Guidelines

Software architecture revolves around separating the stable parts of a system from the change‑prone parts, ensuring that the model remains stable while implementation details evolve.

Single Responsibility Principle (SRP) : each class or method should have only one responsibility, reducing complexity and improving maintainability.

public interface UserService{
    Object register(Object param);
    Object login(Object param);
    Object queryUserInfoById(Long uid);
}

When new features such as project participation are added, the UserService class can become bloated. The solution is to extract a dedicated ProjectService:

public interface ProjectService{
    void addProject(Object param);
    void countProject(Object param);
}

Open‑Closed Principle (OCP) : software entities should be open for extension but closed for modification. By defining an abstract payment channel and implementing concrete subclasses, new payment methods can be added without altering existing code.

abstract class AbstractPayChannel{
    public Object pay(Object requestParam){
        // abstract method
    }
}
class WeixinPayChannel extends AbstractPayChannel{
    public Object pay(Object requestParam){
        // WeChat payment logic
    }
}
class AliayPayChannel extends AbstractPayChannel{
    public Object pay(Object requestParam){
        // Alipay payment logic
    }
}

Liskov Substitution Principle (LSP) : subclasses must be usable wherever their base class is expected without altering program correctness.

Interface Segregation Principle (ISP) : split large interfaces into smaller, client‑specific ones. For example, a separate BopsUserService provides a delete operation only for privileged back‑office systems.

public interface BopsUserService{
    Object deleteById(Long uid);
}

Dependency Inversion Principle (DIP) : high‑level modules should depend on abstractions, not concrete implementations. Using Spring’s @Resource injection, a MessageSender interface can be implemented by KafkaMessageSender or PulsarMessageSender without changing the high‑level handler.

interface MessageSender{
    void send(Message message);
}
class KafkaMessageSender implements MessageSender{
    private KafkaProducer producer;
    public void send(Message message){
        producer.send(new KafkaRecord<>("topic", message));
    }
}

KISS (Keep It Simple and Stupid) : aim for simplicity in design and implementation, avoiding premature optimization, excessive cleverness, and patch‑work code.

Law of Demeter (Least Knowledge) : a class should only talk to its direct friends, reducing coupling and improving modularity.

Contract (Design by Contract) : define precise pre‑conditions, post‑conditions, and invariants for APIs to ensure reliability and version compatibility.

By applying these principles, developers can create clean, extensible, and maintainable backend systems.