Spring System Design in Practice E-Book

Rodrigo Santiago

• Herausgeber: Packt Publishing
• Sprache: Englisch

Seitenzahl: 634

Veröffentlichungsjahr: 2025

Beschreibung

Software system design goes beyond just writing code—it requires a structured approach to translating real-world requirements into scalable, maintainable solutions. With Rodrigo Santiago’s hands-on mentoring style and Java Spring expertise, he makes system design accessible to developers at all levels.
Spring System Design in Practice guides you through building robust software architectures with Spring. From breaking down complex business needs into actionable use cases to implementing services using Spring Boot, this book equips you with the tools and best practices needed for developing secure, high-performance applications. You'll explore inter-service communication, security, and aspect-oriented programming to streamline development. Covering microservices architecture, the book demonstrates how to create self-configuring, resilient, and event-driven services that integrate seamlessly into the cloud. Through hands-on experience, you'll apply best practices to enhance reliability and scalability while tackling complex challenges such as state management, resilience patterns, concurrency issues, and distributed transactions—including bottlenecks related to asynchronous and reactive programming.By the end of this book, you'll have the confidence to analyze system requirements and design well-structured, scalable architectures.

Leseprobe

Spring System Design in Practice

Build scalable web applications using microservices and design patterns in Spring and Spring Boot

Rodrigo Santiago

Spring System Design in Practice

Copyright © 2025 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author nor Packt Publishing or its dealers and distributors will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Portfolio Director: Ashwin Nair

Relationship Lead: Aaron Lazar

Content Engineer: Kinnari Chohan

Project Manager: Ruvika Rao

Technical Editor: Aniket Shetty

Copy Editor: Safis Editing

Proofreader: Kinnari Chohan

Indexer: Rekha Nair

Production Designer: Vijay Kamble

Growth Lead: Anamika Singh

First published: April 2025

Production reference: 1260325

Published by Packt Publishing Ltd.

Grosvenor House

11 St Paul’s Square

Birmingham

B3 1RB, UK

ISBN 978-1-80324-901-8

www.packtpub.com

To my wife, Flavia, who made my world perfectly organized and beautiful, allowing me to focus on writing this book—even as I kept going to bed between 3 and 5 a.m. Thank you for your love, patience, and support. We made it!

To my mother, Valéria, whose unwavering care for people and things has been my lifelong example.To my father, João, who taught me to be relentless and to keep going, no matter what.

And to my children—Valentina, Lavínia, Theo, and Aurora—may this book be a reminder to always dream big, create with passion, and bring great things into the world for great people.

– Rodrigo Santiago

Contributors

About the author

Rodrigo Santiago is a software developer with years of experience streamlining systems and improving products and processes. He has led projects that turned chaotic challenges into high-performance solutions, focusing on areas where small changes had a big impact. Known for his calm and positive approach under pressure, Rodrigo has successfully guided cross-functional teams to deliver results.

Rodrigo has worked in diverse industries, from legal tech to fintech, tackling system architecture and team dynamics. His expertise in system design, microservices, and event-driven architecture has enabled scalable solutions that meet both technical and business needs.

About the reviewer

Ibidapo Abdulazeez is a software engineer with over two years of experience building scalable solutions, particularly in the fintech and real estate sectors. Holding a master’s degree in Computer Science, Abdulazeez is passionate about leveraging technology to address critical challenges in underdeveloped sectors.

With expertise in cloud computing, machine learning, and backend development using Spring, Abdulazeez has worked on projects such as credit card fraud detection systems and student loan accessibility APIs. Aspiring to pursue a PhD in Computer Science, Abdulazeez is committed to driving technological advancements and innovation in the field.

Table of Contents

Preface

Part 1: Foundations for System Design

1

What are the Product Requirements?

Unlocking your finances with the Spring Framework

How is this book structured to help you succeed?

Why do we need to understand business requirements?

Perfecting business requirements

What are business requirements?

Crystal-clear needs – ensuring businesses get requirements right

Visualizing timelines for problem-solving

Crafting business requirements

The pitfalls of product requirements

Are mock designs business requirements?

Requirements should not express technology choices

Does a customer know the problems they are experiencing?

Are solutions the final step?

Breaking the curse of technical debt

Dense documentation

Vague documentation

Looking beyond the happy path

Disregarding other business areas and processes

Assuming too much about other areas

Summary

2

Sorting Complex Requirements into Features, Use Cases, and Stories

Naming the distinct features of your product

Identifying actors, events, life cycles, stages, types, levels, and loops

Who will perform actions in your system?

Defining critical events for each actor

Listing the main features of the system

Extracting a feature’s events timeline

Simplifying requirements

Understanding stages, levels, types, life cycles, and loops

Creating user journeys, stories, and use cases

User journeys

User stories

Use cases descriptions

Structuring the final business requirements document

Which of these artifacts should come first?

Scaling results with long-term business requirements

Exercises

Summary

3

Defining Domains for Your Application

Technical requirements

Determining which features to deliver first

Criteria for prioritizing a business requirement

Sorting priorities

Defining domains and boundaries for your application

What are product domains and why are they important?

Detecting common concepts and eliminating redundancy across use cases

Setting up and defining domains for your product

Setting up domain composition, boundaries, and limits

Defining the right services for your domains

What are services and why should we think about them?

How to model and document domain services correctly

Crafting your domain diagram

Sequencing the activity across services

The Rental Proposal sequence diagram

Introduction to PlantUML as a tool for building sequence diagrams

Summary

4

Defining Services for Your Domains

Understanding non-functional requirements

Handling user requirements

I/O and data maintenance requirements

Exploring sizing requirements

Storage types

Requirements for data processing

Testing requirements

AI, data engineering, and analytics requirements

Disaster recovery capabilities

Choosing protocols

Summary

Part 2: Designing Great Spring Services

5

Writing Your Services – Introducing REST APIs with the Spring Framework

Technical requirements

Moving from domain design to programming

Microservice communication

Introducing the HTTP protocol

What are the main HTTP verbs?

What are the main HTTP response codes?

Writing your first Spring app

Using SDKMAN to manage your tool versions

Using Spring Initializr

Opening your Spring project

Building your application using Gradle

Implementing your first Spring Controller class

Running your Spring Application

Designing your API services

What are APIs?

Why do we need RESTful standards?

Dissecting a RESTful resource address

Adding parameters to your API endpoints

Using payloads in RESTful services

Using UUIDs to uniquely identify objects

Using HTTP request headers

How Spring apps run internally

Introducing the Spring Framework component lifecycle

What are Spring beans and why are they important?

Introducing the Spring Boot project

Understanding the Spring Framework component scan

Where are Spring beans stored at runtime?

How to easily access a Spring bean

Spring container and inversion of control

Creating RESTful APIs in Spring

Writing a rental property REST API with Spring Web

Spring Web cheat sheet

Summary

6

Translating Business Requirements into Well-Designed Spring APIs

Technical requirements

Mastering the blueprint for any Spring microservice

Exploring the vertical layers

Understanding the horizontal layers

Rental proposal service design

Error handling in REST APIs

Implementing business services in Spring

Declaring service interfaces in Spring

Writing the implementation class for your service

Organizing your Spring classes

Writing automated tests for your Spring apps

Understanding the basic test pattern

Creating integrated tests with Spring Test

Testing Beans in isolation

Other testing options

Coming up with a test case list

Perfecting the application tests over time

Running your tests in the console

Tuning Spring Web for peak performance

Making your API design a lot better for clients

Richardson Maturity Model for creating/documenting REST APIs

Summary

7

Handling Data and Evolving Your Microservice

Technical requirements

Data persistence in applications with Spring

Reactive versus non-reactive data handling

Non-reactive data handling

Reactive data handling

SQL versus NoSQL data storage

SQL databases

NoSQL databases

Microservices versus monolith application data design

Data complexity and granularity level

Organizing databases

Implementing non-reactive SQL database persistence

Adding support to a dev database

Defining entities to be persisted

ORM versus raw SQL in Spring Data

JpaRepository – your go-to SQL interface in Spring Data

Using JpaRepository as an ORM-enabled repository

Using Lombok to translate DTO to entity classes and vice versa

JpaRepository class hierarchy made simple

Customizing database queries using JpaRepository

Using JPQL to create custom queries

Understanding other limitations of JpaRepository

Dealing with a very high volume of data and requests

Retrieving paged results in Spring JpaRepository

Using multiple service implementations on your application

Using @Qualifier to inject multiple bean implementations for the same service

How does EntityManager work?

Working with transactions in Spring Data

Using the @Transactional annotation in a method

Managing transactions by using the EntityManager bean

Using NamedParameterJdbcTemplate to run raw SQL queries

Referencing all the implementations we have done so far

Testing your applications with data integration

Summary

Part 3: Security, Performance, and Scalability

8

Securing Services with Spring Security and OAuth 2.0

Understanding the security areas in your application

What is OAuth 2.0 and why use it?

Use case 1 – system A accesses system B-owned resources

Use case 2 – system A accesses its own resources

Basic service types in OAuth 2.0

Industry-grade authorization providers

Understanding how JWTs work

The JWT header

The JWT payload

The JWT signature

Different architectures for validating tokens

Implementing HomeIt security

Creating your project

Creating your security configuration class

Adding Spring Security to the Rental Properties service

Implementing and using refresh tokens

Summary

9

High-Performance Secure Communication Between Spring Services

Technical requirements

Service communication made easy

Adding more security to HomeIt authentication

What is RestAssured?

Writing a high-performance service with WebFlux

Looking at the Revoke Token Service folder structure

Writing the Revoke Token Service properties file

Writing the database schema file

Writing the Revoke Token Service persistence layer

Reactive versus blocking services

Writing the Revoke Token service class

Writing a reactive endpoint Handler class

Writing the RouterConfig and resource addresses

Writing a customized Basic authorization filter

Connecting services with API requests

Adding security filters to your authentication flow

Writing API integration tests with RestAssured

Creating the project structure

Declaring dependencies

Writing the actual tests

Making the actual requests using RestAssured

Summary

10

Building Asynchronous, Event-Driven Systems With NoSQL Databases

Technical requirements

A maintainability issue with RESTful APIs

What is heavy coupling?

How service coupling makes code harder to maintain

Introducing event-driven architectures

What is the difference between a queue and a topic?

How should your notification messages look?

Using Kafka in event-driven services

Kafka main concepts

Installing Kafka on a Linux machine

Using MongoDB for NoSQL persistency

Our event-driven sample in HomeIt

Building our rental proposal service publishers

Combining WebFlux, MongoDB, and Kafka in Spring Services

Streaming object collections with WebFlux

Building our rental properties service consumers

Extending our end-to-end tests

Summary

Part 4: Orchestrating Resilient Services

11

Launching Your Self-Organizing Microservice Cloud

Technical requirements

How to produce your service logs

What are the existing log levels?

How to write logs in Spring

Understanding your log output

How to organize your property files

Writing your properties files

Overriding a property file when starting the packaged application

Setting property values using environment variables

Creating property files per deployment environment

Injecting properties in your services

Setting up your services using Spring Cloud

Understanding the Spring Cloud topology

Launching the Discovery service

Launching the Config service

Setting up your property files on a Git repository

Integrating your services with Spring Cloud

Launching the API Gateway service

Hitting the API gateway with our integration tests

Summary

12

Optimizing Your Services

Technical requirements

Setting the right performance expectations for your project

Failures are unavoidable

Launch early, optimize later

Key bottlenecks that can slow things down

Eliminate single points of failure

Distributed transactions going wrong

Prepare your services for concurrent requests

Using caching to speed up access to critical data

Recovering from failures with dead letter queues

Real-time service monitoring with Spring Actuator

Handling faulty services with Resilience4j

Using the Circuit Breaker pattern

Using the Rate Limiting pattern

Using Retry in Resilience4J

Using the Bulkhead pattern

Preventing race conditions with a SQL trick

Why microservice-level solutions won’t work

A simple and effective solution – database locks

Recovering from failures by using an audit job

Dealing with a surge of requests by using throttling

Summary

Epilogue

Index

Other Books You May Enjoy

Preface

Welcome to this journey into the heart of Spring! If you’ve ever stared at a blank IDE, wondering where to even begin when building a robust, scalable service, you’re not alone. The world of software development is full of grand ideas and ambitious goals, but turning those into well-structured, maintainable applications? That’s both an art and a science. This book is here to help you bridge that gap.

We will start with the foundations because great software is built on clarity. We’ll walk through dissecting requirements, distinguishing between functional and non-functional needs, and transforming them into domain objects and solid API contracts. It’s like laying down the blueprint before building a skyscraper—you wouldn’t want your application to topple at the first gust of real-world complexity.

Then, we’ll roll up our sleeves and get into the real magic: building services with Spring. How should interfaces interact with implementations? What’s a clean way to design services that will grow gracefully over time? We’ll answer these questions and propose a practical blueprint for creating new APIs and communicating seamlessly with other systems. And since security is a non-negotiable in today’s world, we’ll dive into user authentication, token creation, and validation using asymmetric keys.

Of course, no journey is complete without a few obstacles. We’ll face them head-on with testing—unit tests, integration tests, and end-to-end tests—ensuring that what we build is not just functional, but reliable. We’ll also explore event-driven architectures, discuss best practices for handling data integrations with SQL and NoSQL databases, and even build a fully-fledged Spring Cloud application.

But what happens when things go wrong? Because, let’s face it, they will. Services fail, networks break, and race conditions lurk in the shadows. That’s why we’ll also talk about designing for resilience: structuring configurations effectively, handling failures gracefully, and resolving concurrency issues like a seasoned architect.

Throughout this book, we’ll keep things practical. This isn’t an abstract tour of Spring 6’s features; it’s a hands-on guide to building applications that work in the real world—applications that scale, recover from failures, and integrate cleanly with the systems around them. We will work from a sample application that we call the HomeIt app, which connects landlords with tenants interested in renting properties.

So, grab your favorite beverage (coffee, tea, or whatever fuels your coding sessions), fire up your IDE, and let’s build something great together. Welcome to the world of Spring!

Who this book is for

Whether you’re taking your first steps into the world of Spring or you’re an experienced system architect looking to refine your approach to scalable web services, this book has something for you.

If you’re new to Spring, you might feel overwhelmed by its vast ecosystem. Where do you start? How do you structure your application? How do all these components fit together? We’ve been there. That’s why this book walks you through the fundamentals—from dissecting requirements to designing APIs, writing services, integrating databases, and handling security. By the time you finish, you’ll have built a fully functional, production-ready Spring application with confidence.

For system architects and experienced developers, this book provides a structured approach to designing scalable, resilient services. We’ll cover best practices for API design, authentication with asymmetric keys, event-driven architectures, and fault tolerance. If you want to ensure your Spring applications can handle real-world complexity while staying maintainable and performant, this book will help you get there.

This book assumes you have some prior experience with an object-oriented programming language and a basic understanding of how to write Java code. You don’t need to be an expert in software development processes—our goal is to provide a clear framework that will help you take high-level requirements and break them down into a resilient family of services that scale effectively.

So, whether you’re just starting out or refining your craft, let’s dive in and build great things together!

What this book covers

Chapter 1, What Are the Product Requirements?, explores how to capture product requirements in a structured, precise way that sets the foundation for well-defined problems and solutions. Every great system starts with a well-defined purpose. You’ll learn how to identify key business needs and translate them into technical goals that guide development from the very beginning.

Chapter 2, Sorting Complex Requirements into Features, Use Cases, and Stories, untangles the complexity of software projects often starting as a tangled web of expectations by breaking down requirements into clear features, use cases, and user stories. This structured approach ensures that we capture what truly matters while keeping the development process manageable and focused.

Chapter 3, LayinDefining Domains for Your Application, explains how, before we write a single line of code, we need to understand the business domain. In this chapter, we’ll use a key domain-driven design (DDD) technique to create visual representations of our system’s core concepts, ensuring that our models align with real-world business logic.

Chapter 4, Defining Services for Your Domains, explains how functional requirements tell us what the system must do, but technical requirements define how it should operate. We’ll cover the crucial technical constraints and expectations on the technical side, ensuring that our services are built for real-world demands with the right tools in place.

Chapter 5, Writing Your Services – Introducing REST APIs with the Spring Framework, introduces the core principles of RESTful APIs and walks you through creating your first Spring-powered service, complete with controllers, request handling, and responses. Now that we have a strong foundation from the previous chapters, it’s time to start building!

Chapter 6, Translating Business Requirements into Well-Designed Spring APIs, teaches you how to build adaptable Spring services by defining clear interfaces, decoupling implementations, and seamlessly integrating different services with each other. We’ll also cover key concepts of how Spring provides interfaces and implementations for connecting to external systems very efficiently.

Chapter 7, Handling Data and Evolving Your Microservice, explains how data is the lifeblood of any system, and how we handle it determines the flexibility of our services. In this chapter, we’ll explore how to work with relational databases in Spring, how to prototype your service very quickly, and what the different approaches for creating custom queries versus out-of-the-box data connections are that make it easier to retrieve or save data.

Chapter 8, Securing Services with Spring Security and OAuth 2.0, provides a hands-on guide to implementing authentication and authorization using Spring Security and OAuth 2.0, ensuring that our services protect sensitive data while providing seamless user access. Security is non-negotiable in modern applications.

Chapter 9, High-Performance and Secure Communication Between Spring Services, explains why when multiple services need to communicate, performance and security become critical concerns. We’ll dive into strategies for making inter-service communication efficient, secure, and scalable, covering how to create asynchronous services with WebFlux.

Chapter 10, Building Asynchronous, Event-Driven Systems with NoSQL Databases, introduces event-driven architectures, showing how to decouple services using messaging systems and NoSQL databases to build scalable, reactive applications, as not all interactions need to happen in real time.

Chapter 11, Launching Your Self-Organizing Microservice Cloud, explores how to launch a cloud-native Spring application, leveraging service discovery, API gateways, remote configurations, and other critical features that make your services connect to each other smoothly.

Chapter 12, Optimizing Your Services, focuses on critical performance tuning, caching, handling failures gracefully, and improving resilience. From circuit breakers to concurrency solutions and distributed transaction consistency checks, we’ll ensure our services thrive under real-world conditions.

To get the most out of this book

Software/hardware covered in the book

Operating system requirements

Java (22 minimum, 25+ recommended)

Windows, Ubuntu

Spring 6+

Gradle

Intellij Community Edition (optional)

If you are using the digital version of this book, we advise you to type the code yourself or access the code from the book’s GitHub repository (a link is available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

Download the example code files

You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/Spring-System-Design-in-Practice. If there’s an update to the code, it will be updated in the GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “Mount the downloaded WebStorm-10*.dmg disk image file as another disk in your system.”

A block of code is set as follows:

html, body, #map { height: 100%; margin: 0; padding: 0 }

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

[default] exten => s,1,Dial(Zap/1|30) exten => s,2,Voicemail(u100) exten => s,102,Voicemail(b100) exten => i,1,Voicemail(s0)

Any command-line input or output is written as follows:

$ mkdir css $ cd css

Bold: Indicates a new term, an important word, or words that you see onscreen. For instance, words in menus or dialog boxes appear in bold. Here is an example: “Select System info from the Administration panel.”

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share your thoughts

Once you’ve read Spring System Design in Practice, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily.

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below:

https://packt.link/free-ebook/9781803249018

Submit your proof of purchase.That’s it! We’ll send your free PDF and other benefits to your email directly.

Part 1: Foundations for System Design

Before writing a single line of code, we need to understand what we’re building. This part focuses on dissecting product requirements, organizing them into actionable development tasks, and structuring domain models that will form the backbone of our system. By the end of this part, you’ll have a clear path from abstract business needs to a concrete technical vision.

This part includes the following chapters:

Chapter 1, What are Product Requirements?Chapter 2, Sorting Complex Requirements into Features, Use Cases, and StoriesChapter 3, Defining Domains for Your ApplicationChapter 4, Defining Services for Your Domains

1

What are the Product Requirements?

Welcome to a fascinating journey through the Spring Framework!

In this chapter, we will cover the world of the so-called “business” or “product” requirements that can be used across any kind of development work, regardless of the tech stack. These are the system’s heart and soul, the first thing we need to know about our apps. Requirements are what make a product tick. After all, if we’re creating software, we need to have a reason why. It’s important to understand that best practices for software development are not just required in the middle or end of development, but instead, they begin right as we start conceptualizing the project.

That being said, in this chapter, we’re first going to figure out the problems that we’re solving and then we’ll begin to clearly articulate the solutions to those problems.

Here’s what we’ll unpack:

Unlocking your finances with the Spring FrameworkHow is this book structured to help you succeed?Why do we need to understand business requirements?Crystal-clear needs – ensuring businesses get requirements rightThe pitfalls of product requirements

The world of business requirements is packed with insights waiting to be uncovered. As I dove deeper, I was very surprised by the treasures I could mine from past experiences. Missing out on these could mean wasted time, money, and effort. Imagine you’re building your dream house without a blueprint. Sounds risky, right? That’s exactly how vital our software’s blueprint—the requirements—is.

Unlocking your finances with the Spring Framework

Understanding the significance of the Spring Framework in today’s backend development landscape is crucial. It stands as one of the most valuable tools out there. Period.

Much of its prestige is due to its foundation on the Java Virtual Machine (JVM), a cornerstone of technology that’s over 30 years old and boasts extensive market maturity.

The JVM, along with the Java programming language, creates a formidable platform for software development, thanks to its standout features:

The universal compatibility of its compiled packages across operating systemsJVM bytecode’s ability to run on nearly any hardwareThe Java JIT compiler’s optimization of bytecode into native code at runtime, offering high performance close to that of C-language programs without the complexity of memory managementA vast global developer communityOngoing support and yearly improvementsAccess to top-tier IDEs, enhancing the development experience for all programmers

These are just a few of the reasons Java and JVM together form such a powerful platform. And that’s only one reason for the Spring Framework’s acclaim.

Spring Framework experts are highly sought after, and will be into the future.

Moreover, the Spring ecosystem has secured its status as the most beneficial, quickest to implement, and simplest Java programming framework to understand. This distinction is due to the Spring Framework’s adoption of superior design principles among all frameworks available on the market.

Created in 2003, the Spring Framework boasts over two decades of refinement. With each release, the Spring community has diligently preserved the best patterns and standards, discarding what no longer serves its purpose. Can you envision accessing such an extensive collection of tried-and-tested concepts and ideas for your benefit, free of charge?

By specializing in Spring, you gain expertise in the top framework built upon the best programming platform for the most demanding use case: enterprise applications. The Spring Framework is particularly crucial for developing backend microservice architectures, currently the foundation of the world’s largest companies.

Backend microservices in enterprise companies constitute a multi-billion-dollar industry, with Java playing a leading role. Thus, by mastering the Spring Framework, you become an exceptionally valuable professional in the industry, globally. You elevate yourself to a world-class, highly esteemed professional status.

While many excellent frameworks and languages are used in enterprise backend systems, none other offers a framework for enterprise backend scenarios with such a large, active community, numerous job opportunities, and a combination of a well-structured language with an equally structured framework. The Spring ecosystem is unmatched in the market.

“But the Spring Framework is such a complex beast!” This is a common sentiment? The vast landscape of Spring projects can seem overwhelming at first glance.

Diving into the Spring ecosystem might feel like exploring a labyrinth of endless possibilities. For many, sifting through the Spring documentation can seem like a daunting endeavor.

Even the most seasoned developers, including tech leads and staff engineers, often admit to lacking a clear overview of the entire Spring project.

Whether you’re a seasoned programmer in other languages or frameworks or just dipping your toes into Spring, you’ll likely encounter essential questions:

What are my options for building systems with the Spring Framework?What are the key components for system development in Spring?When should I prefer one component over another?How do Spring components and projects work together?What’s the primary use of each Spring project?

By the end of this book, you’ll find yourself able to confidently answer these questions, equipped with a solid understanding of how Spring’s diverse components address real-world development challenges. While no system is without its flaws (yes, bugs are part of the journey), you’re now on the path to learning the Spring ecosystem. Ready to embark on this adventure?

While others may feel uncertain of how to choose Spring components for their specific implementation and business needs, this book offers a clear roadmap. It guides you from understanding the initial business requirements to confidently programming software with the right approach, simplifying what can often seem like a daunting process.

How is this book structured to help you succeed?

By diving into this book, you’ll learn how to decipher even the most challenging business needs. You’ll learn how to transform these needs into clear, actionable use cases, akin to drawing a detailed map that guides how a system should come to life.

Starting with the map (use cases), you will move on to designing a vibrant city (domains, services, and sequence diagrams), and, finally, to constructing the buildings (coding) that stand tall in production. Along the way, we’ll embrace automated tests like a trusted compass, ensuring our development process is not only swift but also efficient and fail-safe.

In this section, we’re tackling the “software developer dilemma” head-on.

In the world of big enterprise companies, software engineers often find themselves at a crossroads—deciding whether to become visionary architects or coding wizards:

Architects spend considerable time in discussions with product teams, working out how to decompose business needs into large work units: services, APIs, and interfaces. They are the professionals skilled in creating high-level designs and distributing well-defined tasks across teams and individual members. Many of them may not have written a line of code in some time, yet their expertise in design and planning remains critical.On the other hand, most programmers prefer working with the well-defined tasks that architects and technical leaders prepare. They enjoy coding independently, often seeking quiet away from business discussions, which they might find less engaging. Programmers typically focus more on the technical aspects of development, rather than directly extracting services from business-centric conversations.

This book is crafted to merge the two worlds of high-level design and detailed programming. It is structured as follows:

Initially, you’ll learn how to discern requirements and translate them into high-level service designs in the first three chapters.Subsequently, Chapters 4 to 10 guide you through addressing technical and non-functional requirements to implement straightforward services with Spring. This includes writing APIs, managing data, ensuring security, and more sophisticated tasks like working with events-based architectures.Advancing further, Chapters 11 and 12 elevate your understanding to construct a complete microservice cloud using Spring, featuring self-recovery, alongside with principles and tips to optimize your service performance.

This book encapsulates this entire journey. I’m excited for you to uncover the full potential of the Spring Framework for both the industry and your career.

I have just one request as you embark on this journey:

Always carry a big smile, especially through the challenges.

Persist in your learning journey; it’s the essence of a fulfilling career in IT and software development. We navigate complex topics with countless variables. Remember, you’re only human, and perfection in software is an evolving target. Your initial code might need refinement, and that’s perfectly normal. Next week, you might spot opportunities for improvement—this cycle is almost inevitable.

Embrace the occasional mistake and address bugs promptly; this mindset will reward you immensely in your career.

Are you ready to adopt this approach and become a leading Spring expert in your organization? Do you aspire to be the top Spring Framework architect where you work?

Let’s dive in without delay!

Why do we need to understand business requirements?

Let’s dive into coding already...

Not so fast! A lack of understanding of business requirements will lead to a lot of misuse of the Spring Framework.

I recognize your eagerness to delve into creating Spring services using the best and most reliable design patterns available in our industry.

I could start by showcasing services built on Spring right at this moment. However, the challenge lies not in the absence of willingness but in the foundational knowledge of where to initiate. The Spring ecosystem is pretty broad, catering to a myriad of use cases, which begs the following questions: What are the pivotal elements? What defines the “beginning” and the “end”?

Indeed, there is no clear “beginning” or “end” within the Spring ecosystem; each component is designed to complement the others. Therefore, the key lies in understanding the specific needs that drive the selection of each component or Spring project. A common hurdle is that many lack insight on which Spring project to choose for their software solutions. More crucially, there’s a widespread challenge in translating real-world demands into effective Spring Framework architecture and implementation strategies.

This gap in the industry stems from developers struggling to grasp customer perspectives, rooted in years of technology-focused discussions and coding, with minimal emphasis on customer engagement or adopting alternative viewpoints. Many software developers find themselves ensnared within their technological paradigms, unable to easily step beyond their confines. Grasping business requirements emerges as a fundamental skill for programmers aspiring to enhance their development capabilities and architectural acumen. It is precisely this skill that we aim to develop through this book.

Perfecting business requirements

This principle will help you avoid very big losses in your Spring implementation, because business requirements are the highest leverage point for steering you and your team toward success—or, conversely, toward failure.

The nuances and variables at play are numerous. A thoroughly crafted requirements document can instill a sense of clarity within the team, making the necessary steps forward appear intuitive. On the other hand, gaps in these requirements can lead to confusion, delays, and, often, unwelcome surprises in daily operations.

I have witnessed numerous adverse outcomes resulting from poorly outlined requirements:

Teams might find themselves discarding months of development workSystems could be launched with missing functionalities, impacting user experienceIntegration issues may only come to light at advanced stages of the projectProject timelines could be repeatedly pushed back, disrupting planned launch datesThe quality assurance team might struggle with what and how to test, leading to potential oversightsPoor architectural decisions are more likely to be made, impacting the project’s long-term sustainabilityShort-sighted choices could incur significant future costsAdditional hours may become necessary to meet deadlines, impacting team morale and project budgets

And so it goes. If you breeze past these initial chapters, heed this playful prophecy: thou shall not know peace in thy projects. Mornings will dawn with the suspense of what fresh chaos awaits in your Slack chats. But fear not! Be the guardian of ensuring all requirements align with these best practices. Do this, and thou art destined for a far more delightful existence as a Spring developer.

What are business requirements?

Business requirements, product requirements, and functional requirements are terms companies use to encapsulate the solutions their systems will provide to customer issues.

Understanding business requirements first requires a grasp of what constitutes a customer’s problem.

So, what exactly is a problem?

Can you succinctly define a customer’s issue? Many have an intuitive sense of problems but struggle to articulate them clearly. It’s a common oversight but many are unaware of their own gaps in specifying or handling business requirements.

This gap in understanding can significantly impact the quality of architectural decisions.

I’ve seen numerous instances where teams went in circles, attempting to pinpoint a product’s purpose. However, with the simple concepts, definitions, and tools I’m about to introduce, organizing and clarifying business needs becomes straightforward. Imagine converting weeks of circular discussions into a productive one-hour session. It’s both powerful and straightforward.

Let’s demystify business requirements with this simple yet profound definition of a “customer problem”:

A customer problem arises from an undesirable situation.

This succinct phrase carries immense weight. It implies that software development should always aim to transition customers from undesirable states to solutions—desired states. Thus, your software should act as a gateway, guiding the customer away from their issue toward a resolution.

Now, getting back to what a business requirement is.

If we understand a problem as an undesirable situation, and the solution as the future, sought-after state, then the business requirement is essentially a compilation of precise statements detailing the actions your software must take to transition the customer from their current predicament to the desired resolution.

Let’s delve deeper into this concept.

Crystal-clear needs – ensuring businesses get requirements right

The methodology that we’ll discuss in this section helps to bring structure and clarity to the conversation about requirements. I have developed it using core concepts I learned in the neuro-linguistic programming field. While we don’t need to get into the technicalities of NLP here, I think learning this way of structuring business requirements will be beneficial in helping you understand the very nature of business requirements.

Business people will usually freely write about the characteristics of the solutions they want to create. But, in fact, there are a few hidden variables at play in that usual, free-text form. When you really understand them, you will be able to spot gaps and missing pieces in any business requirements.

Visualizing timelines for problem-solving

Utilizing a visual timeline simplifies the definition of a business requirement by focusing on two critical junctures: the present and future states. The present state details the customer’s current challenges, while the future state envisions their circumstances after implementing your solution.

Visuals are super important, as we have discovered from brain science. When we use pictures or diagrams, our brain just “lights up” in more places. By using more of our neurons, we understand things better. Our brain is really good at seeing and making sense of pictures. For example, think about how we understand time like it’s a straight line in our heads. That’s us using a picture to grasp a tricky concept. So, when we use visuals to explain systems, it taps into our brain’s strong suit of working with images, making it easier for us to get the hang of things, including very complex business requirements. In short, using pictures isn’t just helpful; it’s a smart and necessary way to make the most of how our brains like to learn and solve things.

The following figure offers a clear framework for understanding the transformative journey your software facilitates for its users:

Figure 1.1 – From problem to solution by using software

For a comprehensive and effective business requirement document, it’s essential to compile statements that vividly illustrate the contrast between the current and future states of the customer. Visualize this document as a two-column layout: the left side details the customer’s present, undesirable situation, while the right side outlines the desirable future state after using your software. Importantly, the document must also specify how the software will facilitate the customer’s transition from the undesirable present to the desirable future.

This structure not only clarifies the purpose and function of the software but also ensures that all stakeholders have a shared understanding of the objectives and the transformative potential of the project.

Taking the example of what problem social media platforms solve, we could put the elements in a basic timeline:

Figure 1.2 – What problem does social media solve?

In the chart, we observe two contrasting phases that delineate life before and after the advent of social media platforms.

On the left side, the scenario depicts a time when customers faced challenges in swiftly and effortlessly staying updated with their friends’ lives on a daily basis. The right side, conversely, portrays the transformative impact of adopting social media, where customers enjoy the convenience of easily and instantly connecting with friends, marking a significant shift toward enhanced communication and social interaction.

This stark contrast highlights the role of social media platforms in bridging communication gaps and fostering connections among users. Of course, there are more problems solved by social media. This is just an example for illustration purposes.

Crafting business requirements

Now that we’ve delineated “problems” and “solutions” within our timeline model, the next crucial step is a comprehensive description of your product. Essentially, your product acts as the conduit transporting customers from their current predicaments to the envisioned solutions.

To ensure your product delivers on its promise, it’s vital to define the attributes and qualities required for it to effectively transition customers from their “problem” state to the “solution” state. This is where the terms business requirements, product requirements, or simply requirements come into play, often used interchangeably across different organizations.

Crafting a complete set of business requirements typically involves a four-step process:

Identify all the problems faced by your customers that your product aims to solve.Define the solutions to clearly articulate how your product should transform the user experience.Outline the high-level requirements for each problem-solution pair, detailing what is necessary to achieve the desired outcome.

Turn the high-level requirements into refined requirements for specific use cases, business rules, and processes that will guide the development and implementation of solutions.

For a more visual representation of these steps, take a look at this figure:

Figure 1.3 – From problems to refined requirements

In the upcoming sections, we’ll dive deeper into each of these steps, providing a clear framework for translating customer needs into actionable product features and functionalities.

Identifying customer’s key problems

Imagine you have recently joined a start-up called HomeIt—a company specializing in helping tenants find the perfect apartment that fits their lifestyle needs.

What could be the problems faced by tenants?

Here are some possible problems we can list. Remember, a “problem” is a description of a present issue, or an undesirable situation faced by your target users:

Not all realtors are trustworthyRental property ads sometimes hide existing problemsRelationships with landlords and realtors can be difficult to manageThere are a limited number of payment options availableContracts take a long time to be finalizedThere is a lack of good insurance options

What other problems can you imagine that tenants face during the experience of renting a home? Take some time to think about it before moving on to the next section.

Creating a matrix of problem-solution statements

Now that we have created a list of current problems tenants face, let’s create a list of possible solutions to each problem. There could be more than one solution to each problem:

Not all realtors are trustworthy:Provide a list of trustworthy realtorsRental property ads sometimes hide existing problems:Allow tenants to report issues not mentioned in the property ads that they might find when moving into a rental propertyCompensate tenants when they find unreported issues in rental propertiesA limited number of payment options are available:Offer different types of payment optionsMake payments easy and fast for all parties—realtors, landlords, and tenantsProvide financial guarantees for landlords, in case tenants cannot pay their rent in a specific monthProvide a financial guarantee for tenants, in case they cannot pay their rent in a specific month

I’m not considering that some of these solutions might not be commercially viable. The examples offered here are for illustration purposes only.

Now that I have provided some solution samples, you can continue the exercise and provide new samples for the other problems mentioned in the earlier section. You can also use the problem samples you came up with to create new solutions.

Take some time to carry out this exercise before moving on to the next section.

Describing the high-level requirements for a solution

Now that we’ve pinpointed the issues our customers face and the solutions they need, let’s outline the kind of software necessary to transition them from facing problems to embracing solutions.

Consider this scenario for HomeIt:

Figure 1.4 – HomeIt problem and solution sample

What are the required features that the HomeIt system should provide in this case?

Let’s work with some simple paragraphs that illustrate the product’s value, as an example:

Our system will equip every realtor with a business quality score, a 1- to 5-star rating derived from feedback given by tenants and landlords after successful dealings. This feature will act like a trust meter, helping users make informed decisions by choosing to partner with highly rated professionals.

Moreover, the HomeIt platform will include a mediation feature, enabling tenants, realtors, and landlords to address and resolve conflicts directly within our system. This ensures that any bumps along the road can be smoothed out efficiently, fostering a trusting and supportive community.

Additionally, HomeIt will offer insurance options for both tenants and landlords to safeguard against unexpected incidents potentially caused by other parties.

This trio of features—reliable realtor ratings, straightforward conflict resolution, and comprehensive insurance—lays the groundwork for a trusted environment where everyone can conduct business with peace of mind.

This sample provides a broad overview, focusing on the general actions a system should undertake to transition users from facing problems to enjoying solutions in the future.

At this stage, detailed specifics, business rules, or processes are less critical. Think of this high-level requirement as the initial brainstorming phase, which will be refined later. While we could delve into some rules and details, the main objective now is to lay out ideas openly, without too much concern for precision.

These overarching product requirements outline the vision of our solution.

Adopting this structured approach simplifies identifying customer problems, envisioning goals that resolve these issues, and defining requirements to guide customers toward our envisioned system.

Now it’s your turn. Reflect on the problems and solutions we’ve discussed and outline some high-level requirements for the HomeIt start-up.

In upcoming chapters, we’ll delve into the “Refine” phase, discussing use cases, sequence diagrams, domains, and so on.

In the next section of this chapter, we’ll examine potential pitfalls in defining business requirements. Those principles will save you a ton of time.

The pitfalls of product requirements

The following guidelines were learned through personal experience throughout the years of working on different projects. Even multi-million-dollar monthly revenue products could bear such mistakes. Letting these things happen can cost the company a lot of extra time and money, and can lead to technical debt, bad architecture design, delivery delays, and so on. Learn from my experience; you don’t want to let these mistakes happen to you as well.

Are mock designs business requirements?

Though visual mockups and Figma designs are integral to software development today, they are essentially interpretations of well-defined business requirements.

This is important to note, as sometimes you may question whether a mock user journey for a feature will actually and fully deliver the requirements. As a software engineer and analyst, it is also your responsibility to double-check whether the suggested visuals will lead to issues during development, in the user journey, or in performance—or even if the visuals identify business rules that were not made explicit in the business requirements and use cases (more about use cases in the next chapter).

In instances where visual representations are provided without explicit business requirements, development risks become pronounced. Clear, written statements defining the product team’s expectations are indispensable for a smooth development process.

Requirements should not express technology choices

It’s common in our field to encounter business requirements that prescribe technical methods for implementing a feature. However, it’s crucial to understand that technical suggestions should not be confused with what defines a “business requirement.”

Falling into the habit of treating technology directives within requirements as non-negotiable can trap you into limited choices, closing off the possibility of discovering better solutions. This practice can create significant blind spots for businesses.

Another downside of incorporating technology choices into business requirements is it can limit the product team to the capabilities of the chosen technologies. The development team, with its deep understanding of various technologies and their trade-offs, is better positioned to determine the most suitable technology for meeting the requirements.

Pointing out that business requirements should avoid containing technical instructions opens up opportunities for the product team to define features more broadly, with more freedom of thinking. This approach allows for more innovation, giving the development team the freedom to select the optimal implementation methods.

Does a customer know the problems they are experiencing?

It’s quite fascinating that some problems are invisible to customers until solutions are presented. Often, innovative companies are the ones that shed light on these hidden issues, offering solutions to problems customers didn’t even know they had. Indeed, customers might be in less-than-ideal situations without realizing there’s an alternative.

Consider the invention of social media platforms. They introduced a new way for people to quickly share and receive updates from friends. Initially, this service was catered to tech-savvy individuals while others were hesitant or unaware of its benefits. I remember trying to get my friends on board, but they were largely indifferent.

Over time, however, social media has become a universal tool, with even tech-averse grandparents finding value in staying connected. Today, it’s hard to find someone who doesn’t use at least one social media platform. My grandmother, for instance, is now more active on Instagram than I am, and she thoroughly enjoys it.

This shift highlights how social media addressed a need that was once unrecognized. Initially seen as unnecessary by many, it has now become integral to our daily communication.

Are solutions the final step?

Of course, every situation can represent a problem. In such a way, moving the customer to a solution state might actually reveal new situations that could represent problems.

Take our social media scenario as an example. People flock to these platforms for the chance to stay connected with a wide circle of friends and influencers across various life stages. It’s a modern marvel of connectivity.

Yet, here’s the twist: becoming an avid social media user can lead to spending excessive hours scrolling, a potential drain on one’s time, and a source of envy and psychological strain from constant comparison. Not to mention the encouragement to overshare, risking privacy for a moment of online validation. It’s a paradox, right? This incredible solution to foster connections simultaneously breeds a host of new challenges.

This cycle is the heartbeat of innovation. Every solution we devise sheds light on new areas for improvement, signaling endless opportunities for refining and evolving our products. Developing software, much like navigating the waters of social media, is an ongoing cycle of release, feedback, and iteration.

Breaking the curse of technical debt

A technical debt is akin to a financial debt in the realm of software development. It represents coding choices that, while expedient, may lead to complications down the line:

Code lacking automated tests is more susceptible to disruptions from changesPoorly designed software can compromise system stability in live environmentsAn inefficient delivery pipeline might result in downtime during updates

In my experience across various companies, balancing technical debt repayment with feature development isn’t always straightforward. Many teams prioritize new features over addressing underlying issues. Here’s how we can shift that mindset.

Incorporating technical debt solutions into feature delivery

Make it a standard practice to include refactoring efforts with feature updates. This approach ensures that with most new deliveries, we’re also enhancing the system’s architecture and engineering quality.

Actively seek opportunities to integrate refactoring into your technical solutions for product implementations. It’s part of our responsibility to preempt potential issues by improving the system proactively.

A very simple example here would be to mandate the creation of automated tests with every release. This should not only cover new features but also extend testing coverage to existing functionalities that might be under-tested. This strategy gradually increases our system’s reliability, instilling greater confidence in its performance in live settings.

By treating technical debt with the seriousness it deserves, we can ensure a more stable, efficient, and future-proof software ecosystem.

Clarifying how technical debts are letting users down

By examining technical debt and tracing its effects on the user journey, we can identify and measure the problems it causes within the system. Here’s how technical debt might be letting your users down:

Performance issues: Similar to being stuck in a traffic jam, technical debt can slow down processes to the point of user abandonmentData inconsistencies: Users may lose or see their critical data messed up, leading to frustration and trust issuesPoor usability: Complex, unintuitive, or flat-out non-working interfaces can confuse users, making them disappointed or irritatedDeployment delays: Slower updates mean users wait longer for improvements and the company’s time to market can be very badly affected

To truly understand the impact, take the time to quantify how many users are affected by specific instances of technical debt and the severity of these impacts.

When you can directly link poor design decisions to user dissatisfaction, quantifying the wasted time, money, and effort and convincing your product team to prioritize resolving technical debt become significantly easier. Making these connections clear is crucial to advocating for the necessary changes to improve your users’ experience.

If you put a dollar sign to the issues created by technical debt and prove there is a lot of money waste going on, it is basically impossible for the high managers not to prioritize those changes.

Both strategies—making tech debt payment a part of the current release development tasks and measuring the direct user impact—are quite good for gradually allowing the system’s improvements to come about more easily.

Dense documentation

In the realm of bad agile practices, it’s not uncommon to stumble upon requirements documents that are so dense with information that they become indecipherable. This method harks back to the early 2000s when software was delivered on installation CDs, and development cycles could stretch from six months to several years to roll out a bundled update of features.

Fast forward to today, where applications often consist of a network of microservices, occasionally accompanied by legacy monolithic systems. This shift means updates are handled feature by feature, or even partial updates are released daily in production, until a whole feature is ready to be enabled with a feature flag. Realistically, a feature’s description shouldn’t sprawl across more than 1,000 lines, let alone span hundreds of pages.

If you find yourself navigating a sea of details for upcoming feature releases, expected to launch everything simultaneously... it’s time to voice your concerns. Launching a product this way severely deviates from agile principles, which in general are great for implementing smooth transitions and improvements on user journeys. Being off-track from those good agile practices significantly increases the risk of things going awry. Let’s not forget that in the digital age, agility and clarity aren’t just nice to have; they’re essential to success.

Vague documentation

On the flip side, encountering requirements documents that offer nothing more than high-level business goals raises a significant red flag. This lack of detail brings developers to a standstill, unable to initiate coding due to missing processes and business rules.

Developers, while adept at translating complex user needs into functional code, aren’t typically versed in the intricacies of business operations. They’re tech enthusiasts, focused on the latest and greatest in technology, not the minute details of a specific market or the legal nuances of a product. Their strength lies in building, not in divining the unspoken needs of the business or its customers.

In today’s fast-evolving tech landscape, finding talented developers who also grasp user needs is increasingly feasible. These developers, akin to explorers in the vast universe of technology, are always on the lookout for the next ground-breaking tech. Their journey, however, often takes them far from the realms of market specifics and legal intricacies surrounding a product. Unlike product and support teams, who interact closely with customers, developers might not have the same depth of understanding of customer needs or the legal frameworks that shape product development.

If you’re handed requirements that feel more like a teaser than a script, it’s crucial to push back. Request the full story—complete flows and business rules—from the product team. Diving into project planning without this information forces a shift away from your technological expertise and into a realm where, despite your best efforts, the results may not align with the project’s needs. Remember, your primary role is to bring technical solutions to life, not to guess the missing pieces of the business puzzle.

Looking beyond the happy path

In the world of product development, requirement documents often paint a picture where everything runs smoothly, a scenario we fondly refer to as the happy path. It’s like envisioning a road trip with perfect weather and no traffic jams; however, reality begs for a plan B.

Effective requirement documents delve into the realm of “what ifs” to ensure robustness:

What if users stray from the intended use of the product?What if there’s a hiccup in the system’s performance?What if our third-party services temporarily go down?

Good requirements anticipate and plan for any less-than-ideal situation. Ensuring that the requirements document is equipped to navigate the “bad days” is essential. By planning for exceptions and bad scenarios, we equip ourselves to face challenges head-on, and the system will be much more prepared from the start.

Disregarding other business areas and processes

Occasionally, a product manager will provide requirements that do not account for what should happen in other company areas. In product development, ensuring every department is ready to play their part is key to launching a successful service.

Let’s say your company tasks you with developing a groundbreaking new service for the website. You and your team deliver this service to production at an astonishing pace, passing every quality and user acceptance test with flying colors. The launch is a success, customers are thrilled, and purchases are through the roof. But then, a curveball: the department responsible for delivering this service was out of the loop during development. Suddenly, there’s a bottleneck—they’re unprepared for the unique requirements of this new offering.

No matter the size of your organization, it’s vital to ensure no department is left in the dark; to ensure that, you can do the following:

Engage all relevant departments from the start.Ask probing questions to understand how this service integrates into the broader company ecosystem.Ensure the business requirements document reflects the roles and needs of every sector.Have documents signed off by all possible departments, even from the ones not impacted by the changes. It is always good to demonstrate which teams are not involved as well.

By adopting a holistic approach to project planning, you not only prevent last-minute hurdles but also foster a culture of collaboration and innovation.

Assuming too much about other areas

It’s not rare to see product folks bring requirements that might not fully grasp how different parts of the company interact.

For instance, consider you’re working on the product mentioned earlier, and you need to forward a request to the shipping department. It’s crucial not to proceed, even during testing, without first syncing up with the development team in that area.

This advice ties back to a key point: has the requirements document been approved by all crucial stakeholders across the company? It’s essential for this document to be vetted by those who understand the intricacies of our various systems and departments.

Imagine you’re about to embark on a journey. You wouldn’t start without a map that everyone agrees on, right? Jumping into coding based on an unchecked document is like navigating with a misleading map. You risk following the wrong path, built on assumptions that might not stand.

Summary

That’s a wrap on this chapter. We’ve delved into the dos and don’ts of crafting business requirements that pave the way for successful software development.

Here’s the key takeaway: impeccable, well-organized requirements don’t just support good architecture—they’re the foundation. A great system design stems from clearly articulated business needs. Remember, you’re setting the stage for success right from the start.