Software Design and

Architecture
LECTURE 1
Software Design and
Architecture
Understanding how to:
•Architect a system to serve the needs of its users
•Write code that's easy to change
•Write code that's easy to maintain
•Write code that's easy to test
Software Design and
Architecture
Even though you know how to write code to make things work at
least once, the bigger challenge is to figure out how to write code
that makes it easy to change in order to keep up with the current
requirements.

But again, where to start?...

First Principles
Deconstruct a problem all the way down to the atomic
level where we can't deconstruct it anymore, and then
reconstructing a solution from the parts that we're
absolutely sure are true.
First state the goal.
Goal of Software
What is the primary goal of software?
Goal of Software
What is the primary goal of software?
Good Software
Software that doesn't serve the needs of its users, simply isn't
good software.

And since the needs of our users changes often, it's important to
make sure that software was designed in order to be
changed.

If software cannot be changed (easily), that makes it bad

software, because it prevents us from satisfying
the current needs of our users.
 The
Software
Design and
Architectur
e Stack
Khalil Stemmler
@stemmlerjs
The software design and architecture stack shows all of the
layers of software design, from the most high-level concepts to
the most low-level details.
Software Design
and Architecture
Map in 9 stages
Solidbook.io
Stage 1 : Clean Code
At the low-level, a few design choices are:

• being consistent
• preferring meaningful variable, method and class names over
writing comments
• ensuring code is indented and spaced properly
• ensuring all of the tests can run
• writing pure functions with no side effects
• not passing null
Clean Code
My definitive explanation of clean code consists of:
Learning Resources

• Clean Code, by Robert C. Martin

• Refactoring, by Martin Fowler (2nd edition)

• The Pragmatic Programmer, by Andy Hunt and Dave Thomas

• The Design of Everyday Things, by Don Norman

Stage 2 : Programming
Paradigm

"
Clean Archi
tecture
"

This implies that effective software uses a hybrid all 3 programming

paradigms styles at different times.
Learning Resources

• Clean Architecture, by Robert C. Martin

• Domain Modeling Made Functional, by Scott Wlaschin

• Concepts of Programming Languages, Robert W. Sebesta

(10th edition)
Stage 3 : Object-Oriented
Programming
•Object-Oriented programming enable us to create a plugin
architecture and build flexibility into our projects.
•OOP comes with the 4 principles of OOP that help us create rich
domain models.
o Encapsulation,
o Inheritance,
o Polymorphism
o Abstraction
Learning Resources

• Object-Design Style Guide, by Matthias Noback

• Clean Architecture, by Robert C. Martin

• Domain-Driven Design, by Eric Evans

Stage 4 : Design Principles
Object-Oriented Programming is very useful for encapsulating rich
domain models and solving the
3rd type of "Hard Software Problems"- Complex Domains.
But OOP can introduce some design challenges.
 When should I use composition?
 When should I use inheritance?
 When should I use an abstract class?
Design • Composition over inheritance
Principles • Encapsulate what varies
• Program against abstractions, not concretions
Design principles are really
well-established object- • The hollywood principle: "Don't call us, we'll call you"
oriented best practices that • The SOLID principles, especially the Single
you use as railguards. responsibility principle
• DRY (Do Not Repeat Yourself)
• YAGNI (You Aren't Gonna Need It)
Learning Resources

• Head First Design Patterns, by various authors

• GoF Design Patterns, by various authors

Stage 5 : Design Patterns
There are 3 categories of design patterns:
• Creational
• Structural
• Behavioural
1. Creational Patterns
Creational patterns are patterns that control how objects are created.
Examples of creational patterns include:
2. Structural Patterns
Structural patterns are patterns that simplify how we define relationships
between components. Examples of structural design patterns include:
3. Behavioural Patterns
Behavioural patterns are common patterns for facilitating elegant
communication between objects. Examples of behavioral patterns are:
Design Patterns
•Design patterns are great, but sometimes they can add an additional
complexity to our designs. It's important to remember YAGNI and
attempt to keep our designs as simple as possible. Only use design
patterns when you're really sure you need them. You'll know when
you will.
•Design patterns are low-level implementations (closer to classes and
functions).
Learning Resources

• Head First Design Patterns, by various authors

Stage 6 : Architectural Principles
Now we're at a higher level of thinking beyond the class level.
The decisions we make towards organzing and building relationships
between components at the high-level and the low-level, will have a
significant impact on the maintainability, flexibility, and testability of our
project.
The guiding principles that helps you build in the flexibility that your
codebase needs in order to be able to react to new features and
requirements, with as little effort as possible.
Architectural Principles "Clean Architecture"

 Component design principles: The Stable Abstraction Principle,

The Stable Dependency Principle, and The Acyclic Dependency
Principle, for how to organize components, their dependencies,
when to couple them, and the implications of accidentally creating
dependency cycles and relying on unstable components.
 Policy vs. Detail, for understanding how to separate the rules of your
application from the implementation details.
 Boundaries, and how to identify the subdomains that the features of
your application belongs within.
Learning Resources

• Clean Architecture, by Robert C. Martin

Stage 7 : Architectural Styles
Architecture is about identifying what a system needs in order
for it to be successful, and then choosing the architecture that
best fits the requirements.
For example, a system that has a lot of business logic
complexity would benefit from using a layered
architecture to encapsulate that complexity.
A system like Uber needs to be able to handle a lot of real
time-events at once and update drivers' locations, so publish-
subscribe style architecture might be most effective.
Stage 7 : Architectural Styles
Architecture is about identifying what a system needs in order
for it to be successful, and then choosing the architecture that
best fits the requirements.
The 3 categories of architectural styles are
For example, a system
similar to the that has a lot
3 categories of of business logic
design
complexity would benefit from using a layered
patterns, because architectural styles are
architecture to encapsulate that complexity.
design patterns at the high-level.
A system like Uber needs to be able to handle a lot of real
time-events at once and update drivers' locations, so publish-
subscribe style architecture might be most effective.
1. Structural
Projects with varying levels of components and wide-ranging
functionality will either benefit or suffer from adopting a structural
architecture.
Few examples
Example
s
Layered
Architectu
re
An example of cutting the
concerns of an
application vertically by
using a layered
architecture.
2. Messaging
Depending on your project, messaging might be a really important component
to the success of the system. For projects like this, message-based architectures
build on top of functional programming principles and behavioral design
patterns like the observer pattern.
Examples of Message-based
Architecture Style
3. Distributed
A distributed architecture simply means that the components of the
system are deployed separately and operate by communicating over
a network protocol.
Distributed systems can be very effective for scaling throughput,
scaling teams, and delegating (potentially expensive tasks or)
responsibility to other components.
Examples of Distributed
Architecture Style
Learning Resources

• Clean Architecture, by Robert C. Martin

• Software Architect's Handbook, by Joseph

Ingeno
Stage 8 : Architectural Patterns
Architectural patterns explain in greater tactical detail how to actually
implement one of those architectural styles.
Examples
of
Architectur
al Patterns
Learning Resources

• Domain-Driven Design, by Eric Evans

• Implementing Domain-Driven Design, by Vaughn
Vernon
Model View Controller
In MVC, the view holds all the presentation layer code,
the controller translates commands and queries from the view into requests
that are handled by the model and returned by the controller.
Where in the Model (M) do we handle these things?:

• validation logic
• invariant rules
• domain events
• use cases
• complex queries
• and business logic
Object-Relational
mapper
If we simply use an ORM
like Sequelize or TypeORM a
s the model, all that
important stuff to gets left
to interpretation on where it
should go, and it finds itself
in some unspecified layer
between (what should be a
rich) model and
the controller.
solidbook.io
Enterprise Patterns
For each of those things that MVC fails to address, in Domain-Driven Design
specifically, there exist several enterprise patterns to solve them. For
example:
• Entities describe models that have an identity.
• Value Objects are models that have no identity and can be used in order to
encapsulate validation logic.
• Domain Events are events that signify some relevant business event
occurring and can be subscribed to from other components.

Depending on the architectural style you've chosen, there are going to be a ton of
other enterprise patterns for you to learn in order to implement that pattern to it's
fullest potential.
Learning Resources
• Patterns of Enterprise Application Architecture, by
Martin Fowler
• Enterprise Integration Patterns, by Gregor Hohpe
• Domain Driven Design, by Eric Evans
• Implementing Domain-Driven Design, by Vaughn
Vernon
References
•Wikipedia: List of architectural styles and patterns
•Architectural styles vs. architectural patterns vs. design
patterns
•The Clean Architecture