Field-driven design and pattern practice (recommended by Martin Fowler and Eric Evans)

Field-driven design and pattern practice (recommended by Martin Fowler and Eric Evans)

[Author] (Swiss) Jimmy Nilsson [same author's work] [Translator's introduction]
Translated by Zhao Li and Ma Yanxin [same translator's work]
[Book name] Turing programming Series
[Release news agency] People's post and telecommunications Publishing House [book no.] 9787115212771
[Mounting time]
[Publication date] May October 2009 [Opening] 16

Sample free trial: http://www.china-pub.com/192983

Edit recommendations
Recommended by Martin Fowler and Eric Evans.
. NET developers must read this ..
Practice drills on the essence of two famous books: enterprise application architecture model and field-driven design
We will teach you how to break through the barriers between the business layer, data layer, and UI Layer and get through the two channels of Ren du...

[Content Overview]
Patterns, domain-driven design, and test-Driven Development give architects and developers unprecedented capabilities to create powerful, robust, and Maintainable Systems. However, how can we make full use of the potential of these tools in real projects ?. In this book, the author integrates the thoughts and essence of Martin Fowler's enterprise application architecture model and Eric Evans's field-driven design, as well as reconstruction, test-driven development, and other technologies, A large number of C # instances are used to explain the entire process of creating a high-quality enterprise-level application architecture... This book is like a wonderful travel experience. every thought and thought is shining with wisdom, vividly interpreting the author's profound understanding of various design choices in object-oriented development ....

[Directory]
 
Part 1 Background
Chapter 1 value that should be paid attention to is also a value for the past few years
Heavy reflection 2
1.1 overall value 2
1.2 architecture 3
1.2.1 focus: Model 3
1.2.2 second focus: Case 3
1.2.3 if model is emphasized, domain model 6 can be used.
1.2.4 careful handling of database 9
1.2.5 impedance mismatch between Domain Models and relational databases 13
1.2.6 handle distributed with caution 16
1.2.7 message transmission is very important 18
1.3 evaluation of various components of the process 19
1.3.1 pre-architecture design 20
1.3.2 domain-driven design 21
1.3.3 test-Driven Development 22
1.3.4 refactoring 25
1.3.5 select one or a combination 26
1.4 continuous integration 27
1.4.1 solution (or at least a major step in the right direction) 27
1.4.2 lessons learned from my organization 28
1.4.3 more information 28
1.5 do not forget the running mechanism 28
1.5.1 example 29 about when a running mechanism is required
1.5.2 example 29
1.5.3 it is not just our fault 30
1.6 Summary 30
Chapter 1 mode Start 32
2.1 mode overview 32
2.1.1 why learning model 33
2.1.2 What should I pay attention to in terms of pattern 34
2.2 design mode 35
2.3 architecture model 42
2.3.1 example: layer 42
2.3.2 another example: domain model mode 43
2.4 design patterns for specific application types 43
2.5 domain model 48
2.6 Summary 52
Chapter 1 TDD and restructuring 53
3.1 TDD 53th
3.1.1 TDD process 53
3.1.2 demo 54
3.1.3 design result 59
3.1.4 question 61
3.1.5 next stage 62
3.2 simulation and pile 62
3.2.1 typical unit test 62
3.2.2 Declaration of Independence 63
3.2.3 difficult handling factors 64
3.2.4 replace collaboration objects with test piles 64
3.2.5 replace a collaboration object with a simulated object 66
3.2.6 design description 68
3.2.7 conclusion 68
3.2.8 more information 68
3.3 reconstruction 68
3.4 summary 78
Part 2 apply ddd
Chapter 2 new default architecture 80
4.1 basic knowledge of the new default architecture 80
4.1.1 transition from database-centric to domain model-centric 81
4.1.2 pay more attention to DDD 81
4.1.3 Layer Based on DDD 82
4.2 contour 83
4.2.1 questions/features of domain model examples 83
4.2.2 processing features 84
4.2.3 domain model 94 so far
4.3 first attempt to connect the UI and domain model 95
4.3.1 basic goal 95
4.3.2 current focus of simple UI 95
4.3.3 list order 95 for the customer
4.3.4 add order 97
4.3.5 what we saw just now 98
4.4 another dimension 98
4.4.1 location 99 of the Domain Model
4.4.2 isolated or shared instance 99
4.4.3 stateful or stateless domain model instantiation 100
4.4.4 full instantiation or subset instantiation of a domain model 100
4.5 conclusion 101
Chapter 1 advanced design of domain-driven design 5th
5.1 refine the domain model through a simple TDD experiment 102
5.1.1 from the creation of order and orderfactory 103
5.1.2 some domain logic 106
5.1.3 Second task: orderrepo-
Sitory + Order Number 107
5.1.4 rebuilding a Persistent Object: how to set a value of 111 from the external
5.1.5 obtain order list 114
5.1.6 it's time to discuss entities 115
5.1.7 return to the process again 116
5.1.8 Overview 117
5.1.9 create pseudo Implementation of orderrepository 118
5.1.10 save 120
5.1.11 total amount per order: 120
5.1.12 historical customer information 124
5.1.13 instance lifecycle 126
5.1.14 order 128
5.1.15 order introducer 128
5.2 coherent interface 130
5.3 Conclusion 131
Chapter 4 Preparing infrastructure 6th
6.1 Use POCO as the working method 133
6.1.1 object and value object PI 133
6.1.2 use PI 137
6.1.3 runtime and compilation PI 137
6.1.4 PI object/value object cost 137
6.1.5 use pi for repository 139
6.1.6 The cost of a single repository is 143
6.2 processing of storage scenarios 143
6.3 create a pseudo-version mechanism 147
6.3.1 more features of the pseudo-version mechanism 148
6.3.2 Implementation of pseudo version 149
6.3.3 impact unit test 150
6.4 database test 153
6.4.1 reset database 154 before each test
6.4.2 maintain the database status during testing and running 155
6.4.3 reset the data used by the test before the test 156
6.4.4 do not forget the Evolving Model 156
6.4.5 separation unit test and database call test 156
6.5 query 159
6.5.1 single query object 160
6.5.2 cost of Single-group query objects: 161
6.5.3 locate the query 162
6.5.4 use aggregation again as tool 163
6.5.5 use the specification for query 164
6.5.6 select 165 for other queries.
6.6 Conclusion 165
Chapter 1 application rules 7th
7.1 classification of Rules 166
7.2 rule principles and usage 167
7.2.1 two-way rule check: Optional (possible) Active checks, required (and automatic) passive checks 167
7.2.2 all statuses (even the error status) should be 167 that can be saved.
7.2.3 rules should be used efficiently 167
7.2.4 rules should be configurable to add custom rules 167
7.2.5 rules should be put together with the status 167
7.2.6 rules should be highly testable 168
7.2.7 The system should prevent us from entering the wrong status 168
7.3 create API 168
7.3.1 context, context, or context 169
7.3.2 database constraint 169
7.3.3 bind rules to domain-related conversions, or bind rules to infrastructure-related conversions 170
7.3.4 precision principle: All statuses, even the error status, should be 171 of the value that can be saved.
7.4 persistence-related basic rule API requirements 172
7.4.1 Go Back To The detected API problems 173
7.4.2 question 173
7.4.3 incorrect conversion 174 is allowed
7.4.4 What if I forget to check? 174
7.5 focus on domain-related rules 174
7.5.1 rules for cooperation 176
7.5.2 use a collection-based processing method 177
7.5.3 service-based verification 178
7.5.4 try to convert 179
7.5.5 Business ID 180
7.5.6 avoid problems 182
7.5.7 use aggregation again as tool 183
7.6 extended API 183
7.6.1 query the rules used to set the UI 184
7.6.2 make the injection Rule 184 possible
7.7 refine implementation 184
7.7.1 a preliminary implementation of 184
7.7.2 create a rule class and exit the immature stage 189
7.7.3 configure rule list 191
7.7.4 rule list 192
7.7.5 process Sub-list 192
7.7.6 API improvement 193
7.7.7 custom 194
7.7.8 provide metadata for users 195
7.7.9 is the applicable mode to solve this problem? 195
7.7.10 what are complex rules? 195
7.8 bind to persistent abstraction 196
7.8.1 make the verification interface 196 pluggable.
7.8.2 alternative solution for passive verification in storage 197
7.8.3 reuse ing metadata 198
7.9 use generic and anonymous Methods 198
7.10 what did others do 199
7.11 conclusion 200
Part 3 Application of poeaa
Chapter 1 infrastructure for persistence 8th
8.1 persistence infrastructure requirements 203
8.2 Where to store data 204
8.2.1 Ram 204
8.2.2 File System 205
8.2.3 object database 206
8.2.4 relational database 207
8.2.5 use one or more resource managers 207
8.2.6 other factors 207
8.2.7 select and forward 207
8.3 method 208
8.3.1 custom manual encoding 208
8.3.2 custom code generation 209
8.3.3 metadata ing (Object Link (O/R) ing tool) 210
8.3.4 select 211 again
8.4 category 211
8.4.1 domain model style 211
8.4.2 ing tool style 212
8.4.3 start point 212
8.4.4 API focus 213
8.4.5 query style 213
8.4.6 214 advanced database support
8.4.7 other functions 215
8.5 another category: infrastructure model 216
8.5.1 metadata ing: 216 of the metadata type
8.5.2 identification field 217
8.5.3 foreign key ing 219
8.5.4 embedded value 219
8.5.5 successor solution 219
8.5.6 ing 220
8.5.7 operating unit 220
8.5.8 delayed loading/immediate loading 220
8.5.9 concurrent control 221
8.6 conclusion 222
Chapter 4 Application of nhib.pdf 9th
9.1 why does nhib1_223
9.2 introduction to nhib.pdf 224
9.2.1 preparation 224
9.2.2 some ing metadata 225
9.2.3 example 229 of a small API
9.2.4 transaction 231
9.3 persistence infrastructure requirements 232
9.3.1 advanced persistence and transparency 232
9.3.2 specific features required for the lifecycle of a persistent object 233
9.3.3 exercise caution when handling relational database 234
9.4 category 235
9.4.1 domain model style 235
9.4.2 ing tool 235 Style
9.4.3 start point 236
9.4.4 API focus 236
9.4.5 Query Language Style 236
9.4.6 237 support for advanced databases
9.4.7 other functions 239
9.5 another classification: Infrastructure Model 240
9.5.1 metadata ing: Metadata type 240
9.5.2 Id field 240
9.5.3 foreign key ing 241
9.5.4 embedded value 241
9.5.5 successor solution 242
9.5.6 ID ing 243
9.5.7 operating unit 244
9.5.8 delayed loading/immediate loading 244
9.5.9 concurrency control 244
9.5.10 additional features: verification hook 245
9.6 nhib.pdf and DDD 245
9.6.1 Assembly overview 245
9.6.2 isession and repository 246
9.6.3 isession, repository, and transaction 246
9.6.4 what result is 247?
9.7 Conclusion 247
Part 4 next step
Chapter 2 other design technologies of boce 10th
10.1 The context is King 250
10.1.1 layer and partition 250
10.1.2 cause of partition 251
10.1.3 restriction context 252
10.1.4 correlation between the restriction context and the partition 252
10.1.5 scale up DDD project 252
10.1.6 why is the domain model so
Partition 253
10.2 introduction to SOA 253
10.2.1 what is SOA 253
10.2.2 why SOA 253
10.2.3 what is the difference between SOA 254
10.2.4 what is service 254
10.2.5 what is included in the Service 254
10.2.6 in-depth analysis 4 Principles 255
10.2.7 what is service 256?
Positioning of 10.2.8 OO in SOA 256
10.2.9 customer-server and SOA 257
10.2.10 one-way asynchronous message transfer 257
10.2.11 how does SOA improve scalability by 258?
10.2.12 Design of SOA service 258
10.2.13 how services interact 259
10.2.14 SOA and unavailable services 261
10.2.15 complex message transfer processing 262
10.2.16 service scalability 262
10.2.17 summary 263
10.3 control reversal and dependency injection 263
10.3.1 no object is an island 263
10.3.2 factory, registration, and service positioner 265
10.3.3 constructor dependency injection 267
10.3.4 setter dependency injection 269
10.3.5 control reversal 270
10.3.6 use spring. NET Framework dependency injection 271
10.3.7 use picocontainer. Net for automatic assembly 272
10.3.8 nested container 273
10.3.9 comparison between service positioner and dependency injection 275
10.3.10 Summary 275
10.4 Aspect-Oriented Programming 276
277 of Hot Topics
10.4.2 definition of AOP 279
In 10.4.3. net, AOP 280
10.4.4 summary 291
10.5 Conclusion 291
Chapter 4 focus on UI 11th
11.1 conclusion 292
11.2 Model-View-controller mode 293
11.2.1 example: Shoe Shop program of Joe 294
11.2.2 simplified view interface through adapter 299
11.2.3 decoupling controllers from views 299
11.2.4 Combining views and controllers 300
11.2.5 is MVC 300 worth using?
11.3 test-driven web forms 300
11.3.1 background 301
11.3.2 example 301
11.3.3 domain model 302
11.3.4 TDD 302 of GUI
11.3.5 web form implementation 307
11.3.6 summary 309
11.3.7 use nmock to create a simulation 309
11.4 ing and packaging 311
11.4.1 ing and packaging 311
11.4.2 use a representation model to package a domain model 312
11.4.3 map the representation model to the domain model 313
11.4.4 Manage Links 316
11.4.5 status issue 318
11.4.6 last thought 319
11.5 Conclusion 320
11.6 Conclusion 320
Part 5 Appendix
Appendix A model style of other domains 324
Appendix B directory 349 of the modes discussed