Muutke küpsiste eelistusi

E-raamat: Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy

4.44/5 (1250 hinnangut Goodreads-ist)
  • Formaat: 342 pages
  • Ilmumisaeg: 08-Oct-2021
  • Kirjastus: O'Reilly Media
  • Keel: eng
  • ISBN-13: 9781098100087
Teised raamatud teemal:
  • Formaat - EPUB+DRM
  • Hind: 47,96 €*
  • * hind on lõplik, st. muud allahindlused enam ei rakendu
  • Lisa ostukorvi
  • Lisa soovinimekirja
  • See e-raamat on mõeldud ainult isiklikuks kasutamiseks. E-raamatuid ei saa tagastada.
Learning Domain-Driven Design: Aligning Software Architecture and Business StrategySuurem pilt
  • Formaat: 342 pages
  • Ilmumisaeg: 08-Oct-2021
  • Kirjastus: O'Reilly Media
  • Keel: eng
  • ISBN-13: 9781098100087
Teised raamatud teemal:

DRM piirangud

  • Kopeerimine (copy/paste):

    ei ole lubatud

  • Printimine:

    ei ole lubatud

  • Kasutamine:

    Digitaalõiguste kaitse (DRM)
    Kirjastus on väljastanud selle e-raamatu krüpteeritud kujul, mis tähendab, et selle lugemiseks peate installeerima spetsiaalse tarkvara. Samuti peate looma endale  Adobe ID Rohkem infot siin. E-raamatut saab lugeda 1 kasutaja ning alla laadida kuni 6'de seadmesse (kõik autoriseeritud sama Adobe ID-ga).

    Vajalik tarkvara
    Mobiilsetes seadmetes (telefon või tahvelarvuti) lugemiseks peate installeerima selle tasuta rakenduse: PocketBook Reader (iOS / Android)

    PC või Mac seadmes lugemiseks peate installima Adobe Digital Editionsi (Seeon tasuta rakendus spetsiaalselt e-raamatute lugemiseks. Seda ei tohi segamini ajada Adober Reader'iga, mis tõenäoliselt on juba teie arvutisse installeeritud )

    Seda e-raamatut ei saa lugeda Amazon Kindle's. 

Building software is harder than ever. As a developer, you not only have to chase ever-changing technological trends but you also need to understand the business domains behind the software. This practical book provides you with a set of core patterns, principles, and practices for analyzing business domains, understanding business strategy, and, most importantly, aligning software design with its business needs.

Author Vladik Khononov shows you how these practices lead to robust implementation of business logic and help to future-proof software design and architecture. You'll examine the relationship between DDD and other methodologies to ensure you make architectural decisions that meet business requirements. You'll also explore the real-life story of implementing DDD in a startup company.

With this book, you'll learn how to:

  • Use DDD's strategic patterns and practices as well as its tactical patterns and use cases
  • Analyze a client company's business domain and competitive strategy
  • Build a shared understanding of the business domains you encounter
  • Decompose a system into bounded contexts
  • Coordinate the work of multiple teams working together
  • Gradually start implementing domain-driven design
Foreword xiii
Preface xv
Introduction xxiii
Part I Strategic Design
1 Analyzing Business Domains
3(18)
What Is a Business Domain?
3(1)
What Is a Subdomain?
4(10)
Types of Subdomains
4(3)
Comparing Subdomains
7(4)
Identifying Subdomain Boundaries
11(3)
Domain Analysis Examples
14(3)
Gigmaster
14(1)
BusVNext
15(2)
Who Are the Domain Experts?
17(1)
Conclusion
18(1)
Exercises
18(3)
2 Discovering Domain Knowledge
21(12)
Business Problems
21(1)
Knowledge Discovery
22(1)
Communication
22(2)
What Is a Ubiquitous Language?
24(1)
Language of the Business
25(2)
Scenarios
25(1)
Consistency
26(1)
Model of the Business Domain
27(4)
What Is a Model?
27(1)
Effective Modeling
28(1)
Modeling the Business Domain
28(1)
Continuous Effort
29(1)
Tools
29(1)
Challenges
30(1)
Conclusion
31(1)
Exercises
32(1)
3 Managing Domain Complexity
33(16)
Inconsistent Models
33(2)
What Is a Bounded Context?
35(3)
Model Boundaries
36(1)
Ubiquitous Language Refined
37(1)
Scope of a Bounded Context
37(1)
Bounded Contexts Versus Subdomains
38(3)
Subdomains
39(1)
Bounded Contexts
39(1)
The Interplay Between Subdomains and Bounded Contexts
39(2)
Boundaries
41(1)
Physical Boundaries
41(1)
Ownership Boundaries
42(1)
Bounded Contexts in Real Life
42(4)
Semantic Domains
43(1)
Science
43(1)
Buying a Refrigerator
44(2)
Conclusion
46(1)
Exercises
46(3)
4 Integrating Bounded Contexts
49(14)
Cooperation
50(3)
Partnership
50(1)
Shared Kernel
50(3)
Customer-Supplier
53(3)
Conformist
53(1)
Anticorruption Layer
54(1)
Open-Host Service
55(1)
Separate Ways
56(1)
Communication Issues
56(1)
Generic Subdomains
56(1)
Model Differences
56(1)
Context Map
57(2)
Maintenance
58(1)
Limitations
58(1)
Conclusion
59(1)
Exercises
59(4)
Part II Tactical Design
5 Implementing Simple Business Logic
63(12)
Transaction Script
63(6)
Implementation
64(1)
It's Not That Easy!
64(4)
When to Use Transaction Script
68(1)
Active Record
69(3)
Implementation
70(1)
When to Use Active Record
71(1)
Be Pragmatic
72(1)
Conclusion
72(1)
Exercises
72(3)
6 Tackling Complex Business Logic
75(24)
History
75(1)
Domain Model
76(19)
Implementation
77(1)
Building Blocks
77(17)
Managing Complexity
94(1)
Conclusion
95(1)
Exercises
96(3)
7 Modeling the Dimension of Time
99(18)
Event Sourcing
99(9)
Search
104(1)
Analysis
105(2)
Source of Truth
107(1)
Event Store
107(1)
Event-Sourced Domain Model
108(4)
Advantages
110(1)
Disadvantages
111(1)
Frequently Asked Questions
112(3)
Performance
112(2)
Deleting Data
114(1)
Why Can't I Just...?
114(1)
Conclusion
115(1)
Exercises
116(1)
8 Architectural Patterns
117(20)
Business Logic Versus Architectural Patterns
117(1)
Layered Architecture
118(7)
Presentation Layer
118(1)
Business Logic Layer
119(1)
Data Access Layer
119(1)
Communication Between Layers
120(1)
Variation
121(3)
When to Use Layered Architecture
124(1)
Ports & Adapters
125(3)
Terminology
126(1)
Dependency Inversion Principle
126(1)
Integration of Infrastructural Components
127(1)
Variants
128(1)
When to Use Ports & Adapters
128(1)
Command-Query Responsibility Segregation
128(6)
Polyglot Modeling
129(1)
Implementation
129(1)
Projecting Read Models
130(2)
Challenges
132(1)
Model Segregation
133(1)
When to Use CQRS
133(1)
Scope
134(1)
Conclusion
135(1)
Exercises
135(2)
9 Communication Patterns
137(22)
Model Translation
137(6)
Stateless Model Translation
138(3)
Stateful Model Translation
141(2)
Integrating Aggregates
143(11)
Outbox
145(2)
Saga
147(3)
Process Manager
150(4)
Conclusion
154(1)
Exercises
154(5)
Part III Applying Domain-Driven Design in Practice
10 Design Heuristics
159(10)
Heuristic
159(1)
Bounded Contexts
160(1)
Business Logic Implementation Patterns
161(2)
Architectural Patterns
163(1)
Testing Strategy
164(2)
Testing Pyramid
165(1)
Testing Diamond
165(1)
Reversed Testing Pyramid
165(1)
Tactical Design Decision Tree
166(1)
Conclusion
167(1)
Exercises
167(2)
11 Evolving Design Decisions
169(16)
Changes in Domains
169(3)
Core to Generic
170(1)
Generic to Core
170(1)
Supporting to Generic
171(1)
Supporting to Core
171(1)
Core to Supporting
172(1)
Generic to Supporting
172(1)
Strategic Design Concerns
172(1)
Tactical Design Concerns
173(5)
Transaction Script to Active Record
174(1)
Active Record to Domain Model
174(2)
Domain Model to Event-Sourced Domain Model
176(1)
Generating Past Transitions
176(1)
Modeling Migration Events
177(1)
Organizational Changes
178(1)
Partnership to Customer--Supplier
179(1)
Customer--Supplier to Separate Ways
179(1)
Domain Knowledge
179(1)
Growth
180(2)
Subdomains
180(1)
Bounded Contexts
181(1)
Aggregates
182(1)
Conclusion
182(1)
Exercises
183(2)
12 EventStorming
185(16)
What Is EventStorming?
185(1)
Who Should Participate in EventStorming?
186(1)
What Do You Need for EventStorming?
186(1)
The EventStorming Process
187(8)
Step 1 Unstructured Exploration
187(1)
Step 2 Timelines
188(1)
Step 3 Pain Points
189(1)
Step 4 Pivotal Events
190(1)
Step 5 Commands
190(1)
Step 6 Policies
191(1)
Step 7 Read Models
192(1)
Step 8 External Systems
193(1)
Step 9 Aggregates
194(1)
Step 10 Bounded Contexts
194(1)
Variants
195(1)
When to Use EventStorming
196(1)
Facilitation Tips
196(2)
Watch the Dynamics
197(1)
Remote EventStorming
197(1)
Conclusion
198(1)
Exercises
198(3)
13 Domain-Driven Design in the Real World
201(16)
Strategic Analysis
202(2)
Understand the Business Domain
202(1)
Explore the Current Design
203(1)
Modernization Strategy
204(6)
Strategic Modernization
205(2)
Tactical Modernization
207(1)
Cultivate a Ubiquitous Language
207(3)
Pragmatic Domain-Driven Design
210(1)
Selling Domain-Driven Design
211(2)
Undercover Domain-Driven Design
211(2)
Conclusion
213(1)
Exercises
214(3)
Part IV Relationships to Other Methodologies and Patterns
14 Microservices
217(16)
What Is a Service?
217(1)
What Is a Microservice?
218(7)
Method as a Service: Perfect Microservices?
219(1)
Design Goal
220(1)
System Complexity
221(1)
Microservices as Deep Services
222(1)
Microservices as Deep Modules
223(2)
Domain-Driven Design and Microservices' Boundaries
225(4)
Bounded Contexts
225(2)
Aggregates
227(1)
Subdomains
228(1)
Compressing Microservices' Public Interfaces
229(2)
Open-Host Service
229(1)
Anticorruption Layer
230(1)
Conclusion
231(1)
Exercises
232(1)
15 Event-Driven Architecture
233(16)
Event-Driven Architecture
233(1)
Events
234(7)
Events, Commands, and Messages
234(1)
Structure
235(1)
Types of Events
236(5)
Designing Event-Driven Integration
241(5)
Distributed Big Ball of Mud
241(1)
Temporal Coupling
242(1)
Functional Coupling
243(1)
Implementation Coupling
243(1)
Refactoring the Event-Driven Integration
243(2)
Event-Driven Design Heuristics
245(1)
Conclusion
246(1)
Exercises
247(2)
16 Data Mesh
249(18)
Analytical Data Model Versus Transactional Data Model
249(5)
Fact Table
250(2)
Dimension Table
252(1)
Analytical Models
253(1)
Analytical Data Management Platforms
254(5)
Data Warehouse
254(3)
Data Lake
257(1)
Challenges of Data Warehouse and Data Lake Architectures
258(1)
Data Mesh
259(5)
Decompose Data Around Domains
259(2)
Data as a Product
261(1)
Enable Autonomy
262(1)
Build an Ecosystem
262(1)
Combining Data Mesh and Domain-Driven Design
263(1)
Conclusion
264(1)
Exercises
265(2)
Closing Words
267(30)
A Applying DDD: A Case Study
273(16)
B Answers to Exercise Questions
289(8)
References 297(2)
Index 299
Vladik (Vlad) Khononov is a software engineer with over 15 years of industry experience, during which he has worked for companies large and small in roles ranging from webmaster to chief architect. Vlad is a long-time proponent of domain-driven design and evolutionary architecture and currently helps companies make sense of their business domains, untangle monoliths, and tackle complex architectural challenges.
Lisainfo e-raamatute kohta Lisainfo e-raamatute kohta
Püsilink: https://www.kriso.ee/db/97810981000876e.html
Märksõnad: