Should You Follow Proven Designs or Trust Your Own Ideas? A Practical Decision‑Making Process

Reference Best Practices → Contextual Evaluation → Choose the Most Suitable Solution

First stage: avoid premature innovation; study proven designs from multiple real systems, incident experience, and complex modules before creating own solutions.

Absorbing outstanding designs builds technical judgment.

Best Practices Are Conditional

Adopting a practice without checking its preconditions is ineffective. The key question is which solution fits the current scenario.

Example: after an order is created, downstream systems need notification.

Many articles recommend a message queue (MQ). MQ enables the order service to publish an OrderCreated event, with inventory, points, logistics, etc., subscribing, allowing future consumers to be added without modifying the producer.

If the application is a simple monolith with no near‑term split, introducing MQ adds:

Operational cost of the middleware

Potential reliability issues

Duplicate consumption handling

More complex exception management

Additional instance expense

For a simple notification, the MQ layer can increase overall complexity.

A lower‑cost alternative is Spring’s built‑in event mechanism: publish an OrderCreatedEvent and let other services listen, achieving decoupling without the overhead of a separate MQ system.

Choose the solution that best matches the current constraints rather than the most advanced one.

Lacking Judgment Experience

If personal evaluation experience is limited, consult senior teammates to validate a self‑derived proposal rather than asking them to decide outright.

No Senior Mentors Available

Take responsibility: implement the design, ship it, monitor behavior, and revisit when requirements change. Refactor if the design proves inadequate.

Conclusion

Engineering focuses on finding the most appropriate solution within existing constraints, not on pursuing the most complex or cutting‑edge technology.