Software Architecture Foundations by Allen Holub

0**. Intro**

design the complete system
see the big picture
start from user problem (story) instead of implementation
just say fuck UML

1**. The Software Architect**

inspect and adapt loop
leverage what you learn something to the real world
Agile architect is Servant Leader (teaching, coaching, coordinating)
review work → make suggestions → help refine processes
architect don’t involve how to solve the problem instead let them pick the suggestions their own way
agile is no more valuable when it is not working
dot vote on sticky note
collaborate with others teams such as UX, Development, Database Admin and so on,

Good Architecture

Simplicity, Maintainability, Testability
Design Patterns, they address small amount of problems
Improve technical understanding

Thinking Architecturally

Conway’s law: change the structure of the organization to match agile methods
understand the user story
build user story with cross functional teams
N Tier: UI, Business Analyst, Database
change code to agile way to move fast
Incremental vs. up-front design
- build a piece of user story
- BUFD (big up-front design) → db → business logic → UI
- agile: customer → user story → tech
Bottom up vs. Top Down
- DDD: module reflects the business
- Ubiquitous Language in DDD: Speak the language of your customers.
- The same word can mean different things under different contexts. This is okay.
The role of the domain (bounded contexts)
- avoid vendor specific ecosystem (ex: bank)

A Design Process: A Brief Introduction

Requirements gathering: Problem statements and user stories

describe problem
describe solution
need to understand what the user goals are
user story does not describe a computer program
smaller story is better → sticky note work better
once we create a story we will need to refine them

Narrowing: Vertical vs. horizontal splitting

horizontal slicing: user story → db + ui + logic
vertical slicing: narrow the scope as much as we can, we can use FlowChart
narrow the path

Identifying bounded contexts and entities

event storming in DDD: how the agents talk each other (the group of this context is called entity)
domain analyst
agent becomes domain
it’s called event map
Entities are the bounded context in agents, where an agent does contextual work linked to a respective event and action.

Enterprise Architecture (EA)

The organization logic for business process and IT infrastructure reflecting the integration and standardization requirements of company ‘s operation modal - MIT CFIS Research
describe the structure of business
describe how things works (processes)
- how things work within departments
- how people communicate
standardization every fucking things lead to more complexity
must use appropriate tools and strategy
know design patterns ( just design from software engineer)
- define by purpose not by structure

Broad Architectural Pattern

Monolithic (big large execution model)
- evil shortcut is impossible
- time for deployment
- homogeneous problem
- Well structured architecture →
- N-Tier (horizontal) : UI, DB, Logic
- vertical: layer with bounded context which connect with horizontal layer
- Monolithic → internal inefficiency
Microkernel (plugin) architecture
- user interact → plugin → kernel → services (like linux)
- implement via message base or http interface (via network)
- a plugin don’t know what other plugin work
- isolation prevent big-ball-of-mud deps
- plugin are small and easy to write, debug and maintain
- cons: APIs to the kernel are delicate
- cons: new APIs require rewriting plugin
- cons: kernel can brake the whole system
- cons: plugins are indirectly coupled to the kernel
Message queue
- pub/sub model
micro services
- independent monolithic
- distributed
- related to bounded context
- two approach of micro services
  1. use REST like architecture (message with post)
  2. messaging post from messaging arch)
  3. cons: design and runtime complexity
  4. cons: network are slow compared to other alternative
  5. RESOURCE: building Microservices.: design fine grained system by sam newsman
Reactive and choreographed systems
- declarative system
- synchronous service (declartive) send one by one methods (Why can a reactive system be so much faster than a synchronous declarative system?)
- shopping service → sentEmail(), sendBla() → take 200s latency
- reactive reuduce latency: brocast events to do something(
- It will broadcast out to the entire system that something needs to be done.
- RESOURCE: holub on patterns: learning design patterns by looking at code
- read code and go out build stuffs
- learn new things all the time, it’s not the subject that will be boring