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
- use REST like architecture (message with post)
- messaging post from messaging arch)
- cons: design and runtime complexity
- cons: network are slow compared to other alternative
- 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
Top comments (0)