Muutke küpsiste eelistusi

Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures [Pehme köide]

4.27/5 (1047 hinnangut Goodreads-ist)
  • Formaat: Paperback / softback, 450 pages, kõrgus x laius: 232x178 mm
  • Ilmumisaeg: 05-Nov-2021
  • Kirjastus: O'Reilly Media
  • ISBN-10: 1492086894
  • ISBN-13: 9781492086895
Teised raamatud teemal:
  • Pehme köide
  • Hind: 75,81 €*
  • * hind on lõplik, st. muud allahindlused enam ei rakendu
  • Tavahind: 89,19 €
  • Säästad 15%
  • Raamatu kohalejõudmiseks kirjastusest kulub orienteeruvalt 2-4 nädalat
  • Kogus:
  • Lisa ostukorvi
  • Tasuta tarne
  • Tellimisaeg 2-4 nädalat
  • Lisa soovinimekirja
  • Formaat: Paperback / softback, 450 pages, kõrgus x laius: 232x178 mm
  • Ilmumisaeg: 05-Nov-2021
  • Kirjastus: O'Reilly Media
  • ISBN-10: 1492086894
  • ISBN-13: 9781492086895
Teised raamatud teemal:

There are no easy decisions in software architecture. Instead, there are many hard parts--difficult problems or issues with no best practices--that force you to choose among various compromises. With this book, youâ ll learn how to think critically about the trade-offs involved with distributed architectures.

Architecture veterans and practicing consultants Neal Ford, Mark Richards, Pramod Sadalage, and Zhamak Dehghani discuss strategies for choosing an appropriate architecture. By interweaving a story about a fictional group of technology professionals--the Sysops Squad--they examine everything from how to determine service granularity, manage workflows and orchestration, manage and decouple contracts, and manage distributed transactions to how to optimize operational characteristics, such as scalability, elasticity, and performance.

By focusing on commonly asked questions, this book provides techniques to help you discover and weigh the trade-offs as you confront the issues you face as an architect.

  • Analyze trade-offs and effectively document your decisions
  • Make better decisions regarding service granularity
  • Understand the complexities of breaking apart monolithic applications
  • Manage and decouple contracts between services
  • Handle data in a highly distributed architecture
  • Learn patterns to manage workflow and transactions when breaking apart applications
Preface xi
1 What Happens When There Are No "Best Practices"?
1(24)
Why "The Hard Parts"?
2(1)
Giving Timeless Advice About Software Architecture
3(1)
The Importance of Data in Architecture
4(1)
Architectural Decision Records
5(1)
Architecture Fitness Functions
6(7)
Using Fitness Functions
7(6)
Architecture Versus Design: Keeping Definitions Simple
13(2)
Introducing the Sysops Squad Saga
15(10)
Nonticketing Workflow
16(1)
Ticketing Workflow
17(1)
A Bad Scenario
17(1)
Sysops Squad Architectural Components
18(1)
Sysops Squad Data Model
19(6)
Part I Pulling Things Apart
2 Discerning Coupling in Software Architecture
25(20)
Architecture (Quantum I Quanta)
28(14)
Independently Deployable
29(1)
High Functional Cohesion
30(1)
High Static Coupling
30(8)
Dynamic Quantum Coupling
38(4)
Sysops Squad Saga: Understanding Quanta
42(3)
3 Architectural Modularity
45(18)
Modularity Drivers
49(10)
Maintainability
50(4)
Testability
54(1)
Deployability
55(1)
Scalability
56(2)
Availability/Fault Tolerance
58(1)
Sysops Squad Saga: Creating a Business Case
59(4)
4 Architectural Decomposition
63(18)
Is the Codebase Decomposable?
65(6)
Afferent and Efferent Coupling
66(1)
Abstractness and Instability
67(2)
Distance from the Main Sequence
69(2)
Component-Based Decomposition
71(2)
Tactical Forking
73(5)
Trade-Offs
77(1)
Sysops Squad Saga: Choosing a Decomposition Approach
78(3)
5 Component-Based Decomposition Patterns
81(50)
Identify and Size Components Pattern
84(10)
Pattern Description
84(3)
Fitness Functions for Governance
87(3)
Sysops Squad Saga: Sizing Components
90(4)
Gather Common Domain Components Pattern
94(7)
Pattern Description
94(1)
Fitness Functions for Governance
95(2)
Sysops Squad Saga: Gathering Common Components
97(4)
Flatten Components Pattern
101(10)
Pattern Description
102(5)
Fitness Functions for Governance
107(1)
Sysops Squad Saga: Flattening Components
107(4)
Determine Component Dependencies Pattern
111(9)
Pattern Description
112(5)
Fitness Functions for Governance
117(1)
Sysops Squad Saga: Identifying Component Dependencies
118(2)
Create Component Domains Pattern
120(6)
Pattern Description
121(1)
Fitness Functions for Governance
122(1)
Sysops Squad Saga: Creating Component Domains
123(3)
Create Domain Services Pattern
126(4)
Pattern Description
126(3)
Fitness Functions for Governance
129(1)
Sysops Squad Saga: Creating Domain Services
129(1)
Summary
130(1)
6 Pulling Apart Operational Data
131(54)
Data Decomposition Drivers
132(19)
Data Disintegrators
133(13)
Data Integrators
146(4)
Sysops Squad Saga: Justifying Database Decomposition
150(1)
Decomposing Monolithic Data
151(10)
Step 1: Analyze Database and Create Data Domains
156(1)
Step 2: Assign Tables to Data Domains
156(2)
Step 3: Separate Database Connections to Data Domains
158(1)
Step 4: Move Schemas to Separate Database Servers
159(2)
Step 5: Switch Over to Independent Database Servers
161(1)
Selecting a Database Type
161(18)
Relational Databases
163(2)
Key-Value Databases
165(2)
Document Databases
167(2)
Column Family Databases
169(2)
Graph Databases
171(2)
NewSQL Databases
173(2)
Cloud Native Databases
175(2)
Time-Series Databases
177(2)
Sysops Squad Saga: Polyglot Databases
179(6)
7 Service Granularity
185(34)
Granularity Disintegrators
188(9)
Service Scope and Function
189(2)
Code Volatility
191(1)
Scalability and Throughput
192(1)
Fault Tolerance
193(2)
Security
195(1)
Extensibility
196(1)
Granularity Integrators
197(11)
Database Transactions
198(2)
Workflow and Choreography
200(3)
Shared Code
203(2)
Data Relationships
205(3)
Finding the Right Balance
208(1)
Sysops Squad Saga: Ticket Assignment Granularity
209(3)
Sysops Squad Saga: Customer Registration Granularity
212(7)
Part II Putting Things Back Together
8 Reuse Patterns
219(30)
Code Replication
221(2)
When to Use
223(1)
Shared Library
223(5)
Dependency Management and Change Control
224(1)
Versioning Strategies
225(2)
When To Use
227(1)
Shared Service
228(6)
Change Risk
229(2)
Performance
231(1)
Scalability
232(1)
Fault Tolerance
232(2)
When to Use
234(1)
Sidecars and Service Mesh
234(5)
When to Use
239(1)
Sysops Squad Saga: Common Infrastructure Logic
239(3)
Code Reuse: When Does It Add Value?
242(2)
Reuse via Platforms
244(1)
Sysops Squad Saga: Shared Domain Functionality
244(5)
9 Data Ownership and Distributed Transactions
249(34)
Assigning Data Ownership
250(1)
Single Ownership Scenario
251(1)
Common Ownership Scenario
252(1)
Joint Ownership Scenario
253(8)
Table Split Technique
254(2)
Data Domain Technique
256(2)
Delegate Technique
258(3)
Service Consolidation Technique
261(1)
Data Ownership Summary
262(1)
Distributed Transactions
263(4)
Eventual Consistency Patterns
267(12)
Background Synchronization Pattern
269(3)
Orchestrated Request-Based Pattern
272(5)
Event-Based Pattern
277(2)
Sysops Squad Saga: Data Ownership for Ticket Processing
279(4)
10 Distributed Data Access
283(16)
Interservice Communication Pattern
285(2)
Column Schema Replication Pattern
287(1)
Replicated Caching Pattern
288(5)
Data Domain Pattern
293(2)
Sysops Squad Saga: Data Access for Ticket Assignment
295(4)
11 Managing Distributed Workflows
299(24)
Orchestration Communication Style
301(5)
Choreography Communication Style
306(9)
Workflow State Management
311(4)
Trade-Offs Between Orchestration and Choreography
315(2)
State Owner and Coupling
315(2)
Sysops Squad Saga: Managing Workflows
317(6)
12 Transactional Sagas
323(42)
Transactional Saga Patterns
324(27)
Epic Saga(sao) Pattern
325(5)
Phone Tag Saga(sac) Pattern
330(3)
Fairy Tale Saga(seo) Pattern
333(3)
Time Travel Saga(sec) Pattern
336(4)
Fantasy Fiction Saga(aao) Pattern
340(3)
Horror Story(aac) Pattern
343(3)
Parallel Saga(aeo) Pattern
346(3)
Anthology Saga(aec) Pattern
349(2)
State Management and Eventual Consistency
351(5)
Saga State Machines
352(4)
Techniques for Managing Sagas
356(2)
Sysops Squad Saga: Atomic Transactions and Compensating Updates
358(7)
13 Contracts
365(16)
Strict Versus Loose Contracts
367(9)
Trade-Offs Between Strict and Loose Contracts
370(2)
Contracts in Microservices
372(4)
Stamp Coupling
376(3)
Over-Coupling via Stamp Coupling
376(1)
Bandwidth
377(1)
Stamp Coupling for Workflow Management
378(1)
Sysops Squad Saga: Managing Ticketing Contracts
379(2)
14 Managing Analytical Data
381(18)
Previous Approaches
382(7)
The Data Warehouse
382(4)
The Data Lake
386(3)
The Data Mesh
389(5)
Definition of Data Mesh
389(1)
Data Product Quantum
390(3)
Data Mesh, Coupling, and Architecture Quantum
393(1)
When to Use Data Mesh
393(1)
Sysops Squad Saga: Data Mesh
394(5)
15 Build Your Own Trade-Off Analysis
399(18)
Finding Entangled Dimensions
401(3)
Coupling
401(1)
Analyze Coupling Points
402(1)
Assess Trade-Offs
403(1)
Trade-Off Techniques
404(12)
Qualitative Versus Quantative Analysis
404(1)
MECE Lists
404(1)
The "Out-of-Context" Trap
405(3)
Model Relevant Domain Cases
408(2)
Prefer Bottom Line over Overwhelming Evidence
410(2)
Avoiding Snake Oil and Evangelism
412(4)
Sysops Squad Saga: Epilogue
416(1)
A Concept and Term References 417(2)
B Architecture Decision Record References 419(2)
C Trade-Off References 421(4)
Index 425
Neal Ford is a director, software architect, and meme wrangler at ThoughtWorks, a software company and a community of passionate, purpose-led individuals who think disruptively to deliver technology to address the toughest challenges, all while seeking to revolutionize the IT industry and create positive social change. He's an internationally recognized expert on software development and delivery, especially in the intersection of Agile engineering techniques and software architecture. Neal has authored seven books (and counting), a number of magazine articles, and dozens of video presentations and spoken at hundreds of developers conferences worldwide. His topics include software architecture, continuous delivery, functional programming, cutting-edge software innovations, and a business-focused book and video on improving technical presentations. Check out his website, Nealford.com. Mark Richards is an experienced, hands-on software architect involved in the architecture, design, and implementation of microservices architectures, service-oriented architectures, and distributed systems in a variety of technologies. He has been in the software industry since 1983 and has significant experience and expertise in application, integration, and enterprise architecture. Mark served as the president of the New England Java Users Group from 1999 through 2003. He is the author of numerous technical books and videos, including the Fundamentals of Software Architecture, Software Architecture Fundamentals Video Series, and several books and videos on microservices as well as enterprise messaging. Mark is also a conference speaker and trainer and has spoken at hundreds of conferences and user groups around the world on a variety of enterprise-related technical topics.