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
Contributors
Preface
Index

The C4 model


In general, if something is not visible, it won't provide the desired effect. Even the most advanced software, produced with the most cutting-edge technology, is entirely useless if the team that works on it is unable to understand it. All of the efforts applied by the team will be a waste of time.

Simply designing a software architecture isn't enough. It has to be shared with the whole team in a way that allows them to use it correctly when fulfilling their activities. The documentation made by the architects speaks for them today, when they should be doing things other than answering a hundred questions about software architecture, and it speaks for them tomorrow when they have left the project and someone else is in charge of its evolution and maintenance.

The second principle of the agile manifesto (http://agilemanifesto.org) is that "teams should value working software over comprehensive documentation." This is often interpreted incorrectly by people believing that no documentation...