Book Image

Software Architecture with Spring 5.0

By : René Enríquez, Alberto Salazar
Book Image

Software Architecture with Spring 5.0

By: René Enríquez, Alberto Salazar

Overview of this book

Spring 5 and its ecosystem can be used to build robust architectures effectively. Software architecture is the underlying piece that helps us accomplish our business goals whilst supporting the features that a product demands. This book explains in detail how to choose the right architecture and apply best practices during your software development cycle to avoid technical debt and support every business requirement. Choosing the right architecture model to support your business requirements is one of the key decisions you need to take when a new product is being created from scratch or is being refactored to support new business demands. This book gives you insights into the most common architectural models and guides you when and where they can be used. During this journey, you’ll see cutting-edge technologies surrounding the Spring products, and understand how to use agile techniques such as DevOps and continuous delivery to take your software to production effectively. By the end of this book, you’ll not only know the ins and outs of Spring, but also be able to make critical design decisions that surpass your clients’ expectations.
Table of Contents (21 chapters)
Title Page
Copyright and Credits
Packt Upsell

Conway's law

Mel Conway published a paper in 1968 that is still relevant today, stating the direction that companies should move in. For a long time, we focused on defining rules for everything, such as the following:

  • What time you should arrive at the office
  • The minimum hours that people should work 
  • How many days per week are used for working
  • What type of clothing is appropriate to wear during working hours


These rules apply to any type of company, and, in many cases, they are still relevant today. Within the IT world (and particularly the software industry), we created another set of rules to guide our teams (feel free to avoid reading these rules if you don't want to get bored):

  • Business analysts should create use cases with a well-defined structure, allowing the developer to ignore the business details and focus on the technical part of the process.
  • Developers should follow the standard document created by the software architect of the product that was written many years ago.
  • The lines of code written per day should indicate how productive a developer is.
  • When you create a new database object, you have to update the existing trustable database dictionary.
  • As soon as your code is ready to be pushed, use an email template to ask for revision by the QA team. After their approval, repeat this process with the design team and later again with the architecture team.
  • Any change to the pushed code will force you to repeat the process that was explained in the preceding rule.
  • Don't forget UML diagrams when you finish coding your assigned use case. Not all of them are required—only the most important ones, such as those listed here:
    • Class diagram
    • Object diagram
    • Package diagram
    • Component diagram
    • Sequence diagram
    • Deployment diagram

The preceding list of diagrams will be larger in some cases. Fortunately, things have changed nowadays, and crazy processes that force us to write huge documents and create different diagrams that pay no attention are no longer used. With these premises in mind, Mel Conway wrote the following as part of his paper:

"Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure."

Conway's thesis is still relevant and has been affecting the way we structure our teams to create successful projects and avoid wasting resources ever since.



People comprise teams, and the question of how these people should be arranged in order to create successful teams has been answered in many ways in the last few years. All of these answers have suggested building small and multidisciplinary teams that should be small enough to be fed using one pizza and multidisciplinary enough to avoid creating silos during the SDLC.

In this way, companies are promoting a culture of sharing and continuous learning within teams. Teams are continually learning from their successes and failures. They are interacting with each other directly instead of using intermediaries or other protocols of communication.

Business boundaries are defined by teams that allow them to communicate using well-defined interfaces, and since the communication is directly managed by themselves, rapid feedback will enable them to fix issues and take corrective actions when necessary.