Head First Software Architecture Chorzów

What will you learn from this book?If you're a software developer looking for a quick on-ramp to software architecture, this handy guide is a great place to start. From the authors of Fundamentals of Software Architecture, Head First Software Architecture teaches you how to think architecturally and explores the unique challenges of software architecture. You'll learn the distinction between architecture and design and the relationship between code, components, and architectural styles. You'll also learn how to work with some common architectural styles through vivid, fun examples. Quick, easy, and entertaining, this book is a valuable introduction to the world of software architecture.Why does this book look so different?Based on the latest research in cognitive science and learning theory, Head First Software Architecture uses a visually rich format to engage your mind, rather than a text-heavy approach that puts you to sleep. Why waste your time struggling with new concepts? This multisensory learning experience is designed for the way your brain really works. Spis treści: OReilly Books Table of Contents (the real thing) How to use this Book: Intro Who is this book for? Who should probably back away from this book? We know what youre thinking We know what your brain is thinking This must be important! Dont forget it! Metacognition: Thinking about thinking So just how DO you get your brain to treat software architecture like its a hungry tiger? Heres what WE did Heres what YOU can do to bend your brain into submission Read me We break things down, then build them back again. We dont exhaustively cover everything. The activities are NOT optional. The redundancy is intentional and important. The examples are as generic as possible. The Brain Power exercises dont always have answers. OReilly online learning Do it yourself chapters The technical review team Joint acknowledgments Individual acknowledgments 1. Software Architecture Demystified: Lets Get Started! Building your understanding of software architecture Building plans and software architecture The dimensions of software architecture Puzzling out the dimensions The first dimension: Architectural characteristics The second dimension: Architectural decisions The third dimension: Logical components The fourth dimension: Architectural styles A design perspective An architectural perspective The spectrum between architecture and design Where along the spectrum does your decision fall? Is it strategic or tactical? How much effort will it take to construct or change? Does it have significant trade-offs? Strategic versus tactical High versus low levels of effort Code Magnets Significant versus less-significant trade-offs Putting it all together You made it! Software Architecture Crossword Code Magnets Solution Software Architecture Crossword Solution 2. Architectural Characteristics: Know Your Capabilities Causing Lafter Cubicle conversation What are architectural characteristics? Defining architectural characteristics Characteristics are nondomain design considerations Characteristics influence architectural structure Limit characteristics to prevent overengineering Consider explicit and implicit capabilities The International Zoo of -ilities Process architectural characteristics Structural architectural characteristics Operational architectural characteristics Cross-cutting architectural characteristics Sourcing architectural characteristics from the problem domain Sourcing architectural characteristics from environmental awareness Sourcing architectural characteristics from holistic domain knowledge Composite architectural characteristics Priorities are contextual Lost in translation Architectural characteristics and logical components Architectural characteristics capabilities Logical components = behavior Balancing domain considerations and architectural characteristics Limiting architectural characteristics The magical number 7 Characteristics Crossword Characteristics Crossword Solution 3. The Two Laws of Software Architecture: Everythings a Trade-Off It starts with a sneaker app What do we know so far? Communicating with downstream services Analyzing trade-offs Trade-off analysis: Queue edition Trade-off analysis: Topic edition The first law of software architecture It always comes back to trade-offs Making an architectural decision What else makes a decision architectural? The second law of software architecture Architectural decision records (ADRs) Cubicle conversation Writing ADRs: Getting the title right Writing ADRs: Whats your status? Writing ADRs: Whats your status? (recap) Writing ADRs: Establishing the context Writing ADRs: Communicating the decision Writing ADRs: Considering the consequences Writing ADRs: Ensuring governance Writing ADRs: Closing notes The benefits of ADRs Two Many Sneakers is a success Two Laws Crossword Two Laws Crossword Solution 4. Logical Components: The Building Blocks Logical components revisited Adventurous Auctions goes online Logical versus physical architecture Creating a logical architecture Step 1: Identifying initial core components Workflow approach Actor/action approach The entity trap Step 2: Assign requirements Step 3: Analyze roles and responsibilities Sticking to cohesion Step 4: Analyze characteristics The Bid Capture component Component coupling Afferent coupling Efferent coupling Measuring coupling A tightly coupled system Applying the Law of Demeter A balancing act Some final words about components Logical Components Crossword Logical Components Crossword Solution 5. Architectural Styles: Categorization and Philosophies There are lots of architectural styles The world of architectural styles Partitioning: Technical versus domain Deployment model: Monolithic versus distributed Monolithic deployment models: The pros Monolithic: The cons Distributed deployment models: The pros Distributed deployment models: The cons Fireside Chats And thats a wrap! Stylin Architectures Crossword Stylin Architectures Crossword Solution 6. Layered Architecture: Separating Concerns Naan & Pop: Gathering requirements Cubicle conversation Design patterns redux Layering MVC Layering it on Translating layers into code Domains, components, and layers Drivers for layered architecture Layers, meet the real world: Physical architectures Physical architecture trade-offs Cubicle conversation One final caveat about domain changes Layered architecture superpowers Layered architecture kryptonite Layered architecture star ratings Wrapping it up Layered Architecture Crossword Layered Architecture Crossword Solution 7. Modular Monoliths: Driven by the Domain Cubicle conversation Modular monolith? Domain pains changes Why modular monoliths? Show me the code! Cubicle conversation, continued... Keeping modules modular Keeping modules modular (last time!) Taking modularity all the way to the database Beware of joins Modular monolith superpowers Modular monolith kryptonite Modular monolith star ratings Naan & Pop is delivering pizza! Modular Monolith Crossword Modular Monolith Crossword Solution 8. Microkernel Architecture: Crafting Customizations The benefits of Going Green Cubicle conversation The two parts of microkernel architectures The spectrum of microkern-ality Device assessment service core Encapsulated versus distributed plugins Plugin communication Cubicle conversation Plugin contracts Going Green goes green Microkernel superpowers Microkernel kryptonite Microkernel star ratings Wrapping it up Microkernel Crossword Microkernel Crossword Solution 9. Do It Yourself: The TripEZ Travel App Making travel easier TripEZs user workflow Planning the architecture The architects roadmap Step 1: Identify architectural characteristics Step 2: Identify logical components Step 3: Choose an architectural style Step 4: Document your decision Step 5: Diagram your architecture There are no right (or wrong) answers 10. Microservices Architecture: Bit by Bit Are you feeling okay? Cubicle conversation Whats a microservice? Its my data, not yours How micro is micro? Granularity disintegrators Why should you make microservices smaller? Granularity integrators Why should you make microservices bigger? Its all about balance Sharing functionality Code reuse with a shared service Code reuse with a shared library Fireside Chats Managing workflows Orchestration: Conducting microservices Choreography: Lets dance Microservices architecture superpowers Microservices architecture kryptonite Microservices star ratings Wrapping it up Microservices Crossword Microservices Crossword Solution 11. Event-Driven Architecture: Asynchronous Adventures Too slow Speeding things up Der Nile flows faster than ever What is an event? Events versus messages Initiating and derived events Is anyone listening? Asynchronous communication Fireside Chats Fire-and-forget Asynchronous for the win Synchronous for the win Database topologies Monolithic database Monolithic database topology scorecard Domain-partitioned databases Domain-partitioned databases topology scorecard Database-per-service Database-per-service topology scorecard EDA versus microservices Hybrids: Event-driven microservices Event-driven architecture superpowers Event-driven architecture kryptonite Event-driven architecture star ratings Putting it all together Wrapping up Event-Driven Crossword Event-Driven Crossword Solution 12. Do It Yourself: Testing Your Knowledge Welcome to Make the Grade Student testing workflow Planning the architecture The architects roadmap Step 1: Identify architectural characteristics Step 2: Identify logical components Step 3: Choose an architectural style Step 4: Document your decision Step 5: Diagram your architecture There are no right (or wrong) answers! A. Leftovers: The Top Six Topics We Didnt Cover #1 The coding architect #2 Expectations for architects #3 The soft skills of architecture #4 Diagramming techniques #5 Knowledge depth versus breadth #6 Practicing architecture with katas How to run katas Preparation Discussion Presentation Dont worry. This isnt goodbye. Index