Published April 6, 2020
by Doug Klugh

Keep It DRY

Avoid this design smell by building software from which it is easy to extract and reuse internal components in new environments.  This smell is often caused by dependencies that are tightly integrated with other parts of the system.  Promote mobility by decoupling components from low-level implementations, such as data persistence, logging, user interfaces, etc.  For example, business rules should be encapsulated within components to enable reuse across multiple systems.

Business rules should never be duplicated across multiple systems.  They should be defined, isolated, and maintained in one component — then shared (reused) across any and all systems that require that business rule — using, for example, web services.  You could even have multiple web services defined for that business rule so long as they all reference that one component which defines the business rule (avoiding Anemic Domain Models).  Not only can that business rule be developed and tested in complete isolation, but it can provide consistency and maintainability across every system that uses it.

Isolating business rules within components promotes numerous software qualities, including maintainability, testability, modularity, resiliency (when run within containers), portability, security, etc.  But despite the massive advantages, very few teams take the time to encapsulate business rules within their own components.  You cannot build good software without promoting mobility.  Know what bad software smells like so you can avoid creating it.