The Importance of Separation of Concerns
Code tends to propagate within a team.
Defining roles allows for separating concerns even at the infrastructure level. A system’s behavior is defined by its role. Separating concerns based on behavior promotes the DRY (Don’t Repeat Yourself) principle. This granularity enables the swapping of components. A system’s structure determines how easy it is to adapt the system to new requirements in the short and long term.
Most teams accept the suggestions provided by frameworks and other libraries. Yet, framework conventions are suggestions, not rules.
How software is structured can impact our ability to adapt and evolve it, even in the short term. The question isn’t whether programmers are doing design or not. The question is, are you going to regret your design choices later? Thus, any new change should move the system towards a more straightforward design.
Every change introduced in a system implies making changes to the design.
The experience level could be more relevant, but the structural changes made to the application. You’re always doing design every time you write code. Every programmer is a designer.
