‫Welcome back.
‫In this section, we're going to learn
‫about the most popular and useful Architectural Patterns
‫for modern software systems.
‫But before we talk about any of those patterns,
‫let's have a brief introduction
‫to what Architectural Patterns are and when to use them.
‫Software Architectural Patterns
‫are general repeatable solutions
‫to commonly occurring system design problems.
‫Unlike design patterns, such as a singleton, factory,
‫or strategy that you may have heard of,
‫which are used to organize code within a single application,
‫Software Architectural Patterns are common solutions
‫to software architectural problems
‫that involve multiple components
‫that run a separate runtime units,
‫such as applications or services.
‫Over the years, many software architects have been observing
‫how other companies in similar industries
‫went about solving similar design problems to their own
‫and tried to learn what worked for them and why.
‫Even more importantly,
‫they observed what mistakes were made
‫so that other companies wouldn't have to waste resources
‫repeating those same anti-patterns.
‫Those general software architecture practices
‫that seemed to be successful
‫became what we know as Software Architectural Patterns.
‫Now, let's talk about why we should be using
‫those Software Architectural Patterns.
‫As software architects and system designers,
‫we're not strictly required to follow any of those patterns.
‫However, we do have a few incentives to follow them.
‫The first incentive is to save valuable time and resources
‫for ourselves and our organization.
‫Essentially, if somebody tells us that other companies
‫that had a very similar use case to the problem
‫were trying to solve and operate
‫on a similar scale to ours
‫already found an architecture
‫and development practice that works for them,
‫then it's better for us to take that knowledge and use it
‫instead of reinventing the wheel
‫and trying to come up with something completely new.
‫The second motivation
‫to use an existing Software Architectural Pattern
‫is to mitigate the risk of getting into a situation
‫where our architecture
‫resembles what's called a big ball of mud.
‫The big ball of mud is an anti-pattern of a system
‫that seemingly lacks any structure,
‫where every service talks to every other service,
‫everything is tightly coupled together,
‫all the information is global or duplicated,
‫and there's no clear scope of responsibility
‫for any of the components.
‫It's needless to say
‫that it's not a situation we want to be in.
‫Surprisingly, many companies got into this situation
‫or some variation of that situation
‫due to many reasons such as rapid growth
‫or lack of overarching, well-defined software architecture
‫that the entire organization adhered to.
‫A system that gets into this situation
‫is very hard to develop, maintain, and scale,
‫which can have detrimental consequences for our business.
‫So we definitely want to avoid it.
‫And finally, the third incentive
‫to follow a well-known Software Architectural Pattern
‫is that other software engineers and architects
‫can continue working on our system
‫and can easily carry on and stick to the same architecture
‫because everyone can read about the pattern we're following
‫and understand exactly what to do and what not to do.
‫However, with all of that in mind
‫all the Software Architectural Patterns
‫we're going to learn are just guidelines.
‫And at the end of the day,
‫our job is to define the best software architecture
‫for our use case
‫and apply what is relevant to our unique situation.
‫Before we proceed
‫to learn about the first Architectural Pattern,
‫there's one more thing I want to point out.
‫As systems evolve, certain Architectural Patterns
‫that used to fit our system perfectly
‫may not fit us anymore,
‫and that is expected.
‫At that point, we would need to do some restructuring
‫and potentially migrate
‫to a different Software Architectural Pattern
‫that now fits us better.
‫However, the best part
‫about following those common Architectural Patterns
‫is that many companies
‫already went through such migrations in the past
‫so we can follow their best practices
‫to make those migrations quickly and safely.
‫So now that we got some introduction
‫to what we're going to learn in this section,
‫let's proceed to the next lecture
‫and learn about our first Architectural Pattern.