Change in Clean Architecture
Nicholas Ocket
I turn developers into software design experts. Join the About Coding Dojo!
Hey everybody!
This is the June 2023 edition of my newsletter. A bit late, but I had a tremendous amount of work the past couple of weeks.
In my previous edition, I talked about cohesion and coupling. In case you missed it, you can read all about it here.
This edition is about change in general and then through the perspective of Clean Architecture. We are aiming to enable change with our designs. But how are we going to do that if we don't understand change? Level up your understanding about change in Clean Architecture here.
As usual, I am very interested your feedback. Let me know what you think about it.If this article gets you all excited to start learning about software design (and you should get all excited ;) ), reach out to me on LinkedIn and I will get you started!
Happy learning!
Software Engineering | React.js | TypeScript | Next.js | Python | Web Development | AI
1 年I really liked the phrase "Most of the changes in a code base will come from your stakeholders." Especially true if you haven't aligned with then completely before implementing the solution.
Technical Product Management | Sofico
1 年Nicholas, I thoroughly enjoyed reading this article. It also strongly resonates with my own thoughts. The key takeaway is that changing code is a certainty when creating a successful digital product. This change can encompass new user types (WHO), evolving user needs (WHAT), and evolving ways to fulfill those needs (HOW). To effectively navigate these changes, it is logical to organize the code based on user types, their respective needs, and the strategies employed to meet those needs. While user stories (including WHO + WHAT) and use cases (describing the HOW) are valuable tools, they are often underutilized or misused in practice. However, these techniques play a significant role in aligning development efforts with user requirements. It is also worth noting that user stories can also be used to capture non-functional requirements, although I have observed this practice being overlooked in the companies I have worked for or audited.