The single responsibility principle is simple but critical in good software design. As Robert Martin puts it in his blog The Single Responsibility Principle, “The Single Responsibility Principle (SRP) states that each software module should have one and only one reason to change.” He also does a great job of comparing this to cohesion and coupling, stating that cohesion should increase between things that change for same reason and coupling should decrease for those things that change for different reasons. Funnily enough, while I was reading a post on Stack Overflow I ran into this line, “Good software design has high cohesion and low coupling.”

Designing software is complicated, and the program is typically quite complex. The single responsibility principle not only creates a stronger and smarter structure for your software but one that is more future-proof as well. When changes must be made to your program, only the pieces of your software related to that change will be modified. The low coupling I mentioned earlier will now prevent the possibility of breaking something completely unrelated. I couldn’t count the number of times my entire program would break by modifying one line when I first started coding, because my one class was doing a hundred different things.

This directly relates to what we’re working on in class right now. We are currently working with REST API, specifically creating endpoints in our specification.yaml file. Our next step will be to implement JavaScript execution for these endpoints. When we begin work on this keeping the single responsibility principle in mind will be incredibly important. It can be very easy to couple functions that look related but change for completely different reasons. For example, coupling validating new guest data and inserting the new guest into the database. While they seem very related, they may change for very different reasons. Maybe validation requirements change, causing the validation process to be modified but not the inserting of a new guest. The database structure or storage system may change leading to modifications to how the new guest is inserted but not how they’re validated. Keeping in mind that related things may change for different reasons will be key for my group leading into the next phase of our REST API work.

This principle is one that I plan on carrying with me during my career as a programmer. It will help me create more future-proofed programs in a world where things must be ready to constantly evolve and adapt. Uncle Bob’s blog was incredibly useful in my understanding of this principle on a deeper level. I feel like a stronger programmer after just reading it. I look forward to implementing what I’ve learned as soon as we start working with the JavaScript of our REST API.

From the blog CS@Worcester – DPCS Blog by Daniel Parker and used with permission of the author. All other rights reserved by the author.

Software architecture is one of those concepts that students hear often but rarely get a clear definition of. This week, I chose to read Martin Fowler’s Software Architecture Guide because it went into depth beyond surface-level definitions of architectural thinking that we usually hear. Since our course is so strongly focused on building maintainable and scalable systems, this resource fit perfectly with the themes we have discussed around design decisions and long-term maintainability in software projects.

Fowler opens the guide by addressing one of the most debated questions in the software community: What, really is architecture? He explains how many definitions focus on “high-level components” or “early design decisions,” but argues these views are incomplete. Referring to an email exchange with Ralph Johnson, Fowler insists that architecture is about “the important stuff.” Architecture is not about big diagrams or an early-stage structural choice; it is about experienced developers having a common understanding of the parts of a system that matter for its long-term health. This makes architecture dynamic and changing rather than merely static documentation.

Fowler also describes why architecture matters, even when end users never directly see it: A poor architecture leads to “cruft,” or the buildup of confusing, tangled code that slows down development. Instead of enabling fast delivery, weak internal quality ultimately hurts productivity. The argument here by Fowler is that paying attention to internal structure actually increases delivery speed because developers spend less time fighting the codebase and more time building features. What struck a chord for me in this is how architecture is coupled with practical results: maintainability, reliability, and team productivity.

I chose this article because I really enjoy the topic and wanted to learn more about software architecture in depth. Fowler’s explanation really helped me understand that architectural thinking is something developers grow into by learning to identify what is truly important in a system. This directly connects with the principles we’ve discussed in class around clean code, modularity, and design patterns. Reflecting on the material, I realized that in future software projects, including class assignments, internships, I will have to think about how my design decisions today will affect my ability-and my team’s ability-to maintain or extend the system later. Good architecture supports future evolution, as Fowler put it, and this is something I want to actively apply as I head toward more complex development work.

Resource: https://martinfowler.com/architecture/

From the blog Maria Delia by Maria Delia and used with permission of the author. All other rights reserved by the author.

This semester I finally sat down and untangled the confusing world of software licenses, starting from a basic question: what can you actually protect when you write code? One of the first things I learned is that you cannot copyright a mere idea for a program; copyright law only protects the concrete expression, like source … Read more

From the blog CS@Worcester – BforBuild by Johnson K and used with permission of the author. All other rights reserved by the author.

Getting to grips with making REST API calls felt like finally being able to have a real conversation with the internet. At first the whole thing was a bit too much but once I started to see the patterns emerging, it just became second nature. It all clicked when I realised that a REST API … Read more

From the blog CS@Worcester – BforBuild by Johnson K and used with permission of the author. All other rights reserved by the author.

For this third quarter’s professional development, i read the Treblle post, “How to Structure an Express.js REST API with Best Practices” (https://treblle.com/blog/egergr). The article mostly just talks about on how to properly organize and build RESTful APIs using Express.js while maintaining clean, scalable, and modular code. It covers some key principles like separating app and server logic, implementing a layered architecture, structuring routes and controllers clearly, and designing the API in a way that’s easy to maintain and expand. It also makes mention on the importance of using Docker for containerization and environment consistency, which is essential for deploying APIs reliably across different systems.

I picked this specific resource because i think it ties closely with what we’ve learned in class earlier, taking into account the things like modularity, separation of concerns, and maintainable software design. It helps that we were doing class exercises when it comes to building small web services and understanding how system components interact(at least tangentially when it comes to the guestinfobackend stuff), so reading about how Express.js projects are structured in real-world settings gave a lot of context for people such as myself interested in backend or full-stack development, it’s the kind of practical foundation that helps turn classroom principles into actual coding habits.

From the article, I learned that Express.js isn’t just about setting up endpoints quickly; it’s about creating a clear, layered structure where each part of the API has its own responsibility. In one instance, it recommended dividing the project into three layers: a web layer (for routes and middleware), a service layer (for handling logic and validation), for the other a data layer (for managing database access). I’d say this structure kind of keeps your code modular and easier to debug. Another thing I think is useful was the reminder to containerize the API using docker, which helps standardize development and production environments so you can avoid those “it does/doesn’t work on my machine” problems.

I’d say the article reinforces many of the software architecture concepts we’ve referenced in class, such as modularity, abstraction, and loose coupling. A modular API design definitely makes it easier to scale, test, and maintain which at the end of the day is really the heart of software construction. It also reminded me that tools like Docker play a key role in supporting architecture by making deployment consistent and repeatable, which is just as important as how the code itself is structured.

As a whole, i’d say this article helped me better understand what good backend architecture looks like in practice. It gave me a clearer sense of how to build modular, scalable APIs using Express.js and Docker and i can somewhat see how those principles might carry over into any kind of future coursework and professional projects that i might be part of.

From the blog CS@Worcester – CSTips by Jamaal Gedeon and used with permission of the author. All other rights reserved by the author.