Schweitzer Fachinformationen
Wenn es um professionelles Wissen geht, ist Schweitzer Fachinformationen wegweisend. Kunden aus Recht und Beratung sowie Unternehmen, öffentliche Verwaltungen und Bibliotheken erhalten komplette Lösungen zum Beschaffen, Verwalten und Nutzen von digitalen und gedruckten Medien.
INTRODUCTION xxxv
PART I: THE PRINCIPLES AND PRACTICES OF DOMAIN-DRIVEN DESIGN
CHAPTER 1: WHAT IS DOMAIN-DRIVEN DESIGN? 3
The Challenges of Creating Software for Complex Problem Domains 4
Code Created Without a Common Language 4
A Lack of Organization 5
The Ball of Mud Pattern Stifles Development 5
A Lack of Focus on the Problem Domain 6
How the Patterns of Domain-Driven Design Manage Complexity 6
The Strategic Patterns of DDD 6
Distilling the Problem Domain to Reveal What Is Important 7
Creating a Model to Solve Domain Problems 7
Using a Shared Language to Enable Modeling Collaboration 7
Isolate Models from Ambiguity and Corruption 8
Understanding the Relationships between Contexts 9
The Tactical Patterns of DDD 9
The Problem Space and the Solution Space 9
The Practices and Principles of Domain-Driven Design 11
Focusing on the Core Domain 11
Learning through Collaboration 11
Creating Models through Exploration and Experimentation 11
Communication 11
Understanding the Applicability of a Model 12
Constantly Evolving the Model 12
Popular Misconceptions of Domain-Driven Design 12
Tactical Patterns Are Key to DDD 12
DDD Is a Framework 13
DDD Is a Silver Bullet 13
The Salient Points 13
CHAPTER 2: DISTILLING THE PROBLEM DOMAIN 15
Knowledge Crunching and Collaboration 15
Reaching a Shared Understanding through a Shared Language 16
The Importance of Domain Knowledge 17
The Role of Business Analysts 17
An Ongoing Process 17
Gaining Domain Insight with Domain Experts 18
Domain Experts vs Stakeholders 18
Deeper Understanding for the Business 19
Engaging with Your Domain Experts 19
Patterns for Effective Knowledge Crunching 19
Focus on the Most Interesting Conversations 19
Start from the Use Cases 20
Ask Powerful Questions 20
Sketching 20
Class Responsibility Collaboration Cards 21
Defer the Naming of Concepts in Your Model 21
Behavior-Driven Development 22
Rapid Prototyping 23
Look at Paper-Based Systems 24
Look For Existing Models 24
Understanding Intent 24
Event Storming 25
Impact Mapping 25
Understanding the Business Model 27
Deliberate Discovery 28
Model Exploration Whirlpool 29
The Salient Points 29
CHAPTER 3: FOCUSING ON THE CORE DOMAIN 31
Why Decompose a Problem Domain? 31
How to Capture the Essence of the Problem 32
Look Beyond Requirements 32
Capture the Domain Vision for a Shared Understanding of What Is Core 32
How to Focus on the Core Problem 33
Distilling a Problem Domain 34
Core Domains 35
Treat Your Core Domain as a Product Rather than a Project 36
Generic Domains 37
Supporting Domains 37
How Subdomains Shape a Solution 37
Not All Parts of a System will be Well Designed 37
Focus on Clean Boundaries over Perfect Models 38
The Core Domain Doesn't Always Have to Be Perfect the First Time 39
Build Subdomains for Replacement Rather than Reuse 39
What if You Have no Core Domain? 39
The Salient Points 40
CHAPTER 4: MODEL-DRIVEN DESIGN 41
What Is a Domain Model? 42
The Domain versus the Domain Model 42
The Analysis Model 43
The Code Model 43
The Code Model Is the Primary Expression of the Domain Model 44
Model-Driven Design 44
The Challenges with Upfront Design 44
Team Modeling 45
Using a Ubiquitous Language to Bind the Analysis to the Code Model 47
A Language Will Outlive Your Software 47
The Language of the Business 48
Translation between the Developers and the Business 48
Collaborating on a Ubiquitous Language 48
Carving Out a Language by Working with Concrete Examples 49
Teach Your Domain Experts to Focus on the Problem and Not Jump to a Solution 50
Best Practices for Shaping the Language 51
How to Create Effective Domain Models 52
Don't Let the Truth Get in the Way of a Good Model 52
Model Only What Is Relevant 54
Domain Models Are Temporarily Useful 54
Be Explicit with Terminology 54
Limit Your Abstractions 54
Focus Your Code at the Right Level of Abstraction 55
Abstract Behavior Not Implementations 55
Implement the Model in Code Early and Often 56
Don't Stop at the First Good Idea 56
When to Apply Model-Driven Design 56
If It's Not Worth the Effort Don't Try and Model It 56
Focus on the Core Domain 57
The Salient Points 57
CHAPTER 5: DOMAIN MODEL IMPLEMENTATION PATTERNS 59
The Domain Layer 60
Domain Model Implementation Patterns 60
Domain Model 62
Transaction Script 65
Table Module 67
Active Record 67
Anemic Domain Model 67
Anemic Domain Model and Functional Programming 68
The Salient Points 71
CHAPTER 6: MAINTAINING THE INTEGRITY OF DOMAIN MODELS WITH BOUNDED CONTEXTS 73
The Challenges of a Single Model 74
A Model Can Grow in Complexity 74
Multiple Teams Working on a Single Model 74
Ambiguity in the Language of the Model 75
The Applicability of a Domain Concept 76
Integration with Legacy Code or Third Party Code 78
Your Domain Model Is not Your Enterprise Model 79
Use Bounded Contexts to Divide and Conquer a Large Model 79
Defining a Model's Boundary 82
Define Boundaries around Language 82
Align to Business Capabilities 83
Create Contexts around Teams 83
Try to Retain Some Communication between Teams 84
Context Game 85
The Difference between a Subdomain and a Bounded Context 85
Implementing Bounded Contexts 85
The Salient Points 89
CHAPTER 7: CONTEXT MAPPING 91
A Reality Map 92
The Technical Reality 92
The Organizational Reality 93
Mapping a Relevant Reality 94
X Marks the Spot of the Core Domain 94
Recognising the Relationships between Bounded Contexts 95
Anticorruption Layer 95
Shared Kernel 96
Open Host Service 97
Separate Ways 97
Partnership 98
An Upstream/Downstream Relationship 98
Customer-Supplier 99
Conformist 100
Communicating the Context Map 100
The Strategic Importance of Context Maps 101
Retaining Integrity 101
The Basis for a Plan of Attack 101
Understanding Ownership and Responsibility 101
Revealing Areas of Confusion in Business Work Flow 102
Identifying Nontechnical Obstacles 102
Encourages Good Communication 102
Helps On-Board New Starters 102
The Salient Points 103
CHAPTER 8: APPLICATION ARCHITECTURE 105
Application Architecture 105
Separating the Concerns of Your Application 106
Abstraction from the Complexities of the Domain 106
A Layered Architecture 106
Dependency Inversion 107
The Domain Layer 107
The Application Service Layer 108
The Infrastructural Layers 108
Communication Across Layers 108
Testing in Isolation 109
Don t Share Data Schema between Bounded Contexts 109
Application Architectures versus Architectures for Bounded Contexts 111
Application Services 112
Application Logic versus Domain Logic 114
Defining and Exposing Capabilities 114
Business Use Case Coordination 115
Application Services Represent Use Cases, Not Create, Read, Update, and Delete 115
Domain Layer As an Implementation Detail 115
Domain Reporting 116
Read Models versus Transactional Models 116
Application Clients 117
The Salient Points 120
CHAPTER 9: COMMON PROBLEMS FOR TEAMS STARTING OUT WITH DOMAIN-DRIVEN DESIGN 121
Overemphasizing the Importance of Tactical Patterns 122
Using the Same Architecture for All Bounded Contexts 122
Striving for Tactical Pattern Perfection 122
Mistaking the Building Blocks for the Value of DDD 123
Focusing on Code Rather Than the Principles of DDD 123
Missing the Real Value of DDD: Collaboration, Communication, and Context 124
Producing a Big Ball of Mud Due to Underestimating the Importance of Context 124
Causing Ambiguity and Misinterpretations by Failing to Create a UL 125
Designing Technical-Focused Solutions Due to a Lack of Collaboration 125
Spending Too Much Time on What's Not Important 126
Making Simple Problems Complex 126
Applying DDD Principles to a Trivial Domain with Little Business Expectation 126
Disregarding CRUD as an Antipattern 127
Using the Domain Model Pattern for Every Bounded Context 127
Ask Yourself: Is It Worth This Extra Complexity? 127
Underestimating the Cost of Applying DDD 127
Trying to Succeed Without a Motivated and Focused Team 128
Attempting Collaboration When a Domain Expert Is Not Behind the Project 128
Learning in a Noniterative Development Methodology 128
Applying DDD to Every Problem 129
Sacrificing Pragmatism for Needless Purity 129
Wasted Effort by Seeking Validation 129
Always Striving for Beautiful Code 130
DDD Is About Providing Value 130
The Salient Points 130
CHAPTER 10: APPLYING THE PRINCIPLES, PRACTICES, AND PATTERNS OF DDD 131
Selling DDD 132
Educating Your Team 132
Speaking to Your Business 132
Applying the Principles of DDD 133
Understand the Vision 133
Capture the Required Behaviors 134
Distilling the Problem Space 134
Focus on What Is Important 134
Understand the Reality of the Landscape 135
Modeling a Solution 135
All Problems Are Not Created Equal 136
Engaging with an Expert 136
Select a Behavior and Model Around a Concrete Scenario 137
Collaborate with the Domain Expert on the Most Interesting Parts 137
Evolve UL to Remove Ambiguity 138
Throw Away Your First Model, and Your Second 138
Implement the Model in Code 139
Creating a Domain Model 139
Keep the Solution Simple and Your Code Boring 139
Carve Out an Area of Safety 140
Integrate the Model Early and Often 140
Nontechnical Refactoring 140
Decompose Your Solution Space 140
Rinse and Repeat 141
Exploration and Experimentation 142
Challenge Your Assumptions 142
Modeling Is a Continuous Activity 142
There Are No Wrong Models 142
Supple Code Aids Discovery 143
Making the Implicit Explicit 143
Tackling Ambiguity 144
Give Things a Name 145
A Problem Solver First, A Technologist Second 146
Don't Solve All the Problems 146
How Do I Know That I Am Doing It Right? 146
Good Is Good Enough 147
Practice, Practice, Practice 147
The Salient Points 147
PART II: STRATEGIC PATTERNS: COMMUNICATING BETWEEN BOUNDED CONTEXTS
CHAPTER 11: INTRODUCTION TO BOUNDED CONTEXT INTEGRATION 151
How to Integrate Bounded Contexts 152
Bounded Contexts Are Autonomous 153
The Challenges of Integrating Bounded Contexts at the Code Level 153
Multiple Bounded Contexts Exist within a Solution 153
Namespaces or Projects to Keep Bounded Contexts Separate 154
Integrating via the Database 155
Multiple Teams Working in a Single Codebase 156
Models Blur 156
Use Physical Boundaries to Enforce Clean Models 157
Integrating with Legacy Systems 158
Bubble Context 158
Autonomous Bubble Context 158
Exposing Legacy Systems as Services 160
Integrating Distributed Bounded Contexts 161
Integration Strategies for Distributed Bounded Contexts 161
Database Integration 162
Flat File Integration 163
RPC 164
Messaging 165
REST 165
The Challenges of DDD with Distributed Systems 165
The Problem with RPC 166
RPC Is Harder to Make Resilient 167
RPC Costs More to Scale 167
RPC Involves Tight Coupling 168
Distributed Transactions Hurt Scalability and Reliability 169
Bounded Contexts Don't Have to Be Consistent with Each Other 169
Eventual Consistency 169
Event-Driven Reactive DDD 170
Demonstrating the Resilience and Scalability of Reactive Solutions 171
Challenges and Trade-Offs of Asynchronous Messaging 173
Is RPC Still Relevant? 173
SOA and Reactive DDD 174
View Your Bounded Contexts as SOA Services 175
Decompose Bounded Contexts into Business Components 175
Decompose Business Components into Components 176
Going Even Further with Micro Service Architecture 178
The Salient Points 180
CHAPTER 12: INTEGRATING VIA MESSAGING 181
Messaging Fundamentals 182
Message Bus 182
Reliable Messaging 184
Store-and-Forward 184
Commands and Events 185
Eventual Consistency 186
Building an E-Commerce Application with NServiceBus 186
Designing the System 187
Domain-Driven Design 187
Containers Diagrams 188
Evolutionary Architecture 191
Sending Commands from a Web Application 192
Creating a Web Application to Send Messages with NServiceBus 192
Sending Commands 197
Handling Commands and Publishing Events 200
Creating an NServiceBus Server to Handle Commands 200
Configuring the Solution for Testing and Debugging 201
Publishing Events 204
Subscribing to Events 206
Making External HTTP Calls Reliable with Messaging Gateways 208
Messaging Gateways Improve Fault Tolerance 208
Implementing a Messaging Gateway 209
Controlling Message Retries 212
Eventual Consistency in Practice 215
Dealing with Inconsistency 215
Rolling Forward into New States 215
Bounded Contexts Store All the Data They Need Locally 216
Storage Is Cheap-Keep a Local Copy 217
Common Data Duplication Concerns 223
Pulling It All Together in the UI 224
Business Components Need Their Own APIs 225
Be Wary of Server-Side Orchestration 226
UI Composition with AJAX Data 226
UI Composition with AJAX HTML 226
Sharing Your APIs with the Outside World 227
Maintaining a Messaging Application 227
Message Versioning 228
Backward-Compatible Message Versioning 228
Handling Versioning with NServiceBus's Polymorphic Handlers 229
Monitoring and Scaling 233
Monitoring Errors 233
Monitoring SLAs 234
Scaling Out 235
Integrating a Bounded Context with Mass Transit 235
Messaging Bridge 236
Mass Transit 236
Installing and Configuring Mass Transit 236
Declaring Messages for Use by Mass Transit 238
Creating a Message Handler 239
Subscribing to Events 239
Linking the Systems with a Messaging Bridge 240
Publishing Events 242
Testing It Out 243
Where to Learn More about Mass Transit 243
The Salient Points 243
CHAPTER 13: INTEGRATING VIA HTTP WITH RPC AND REST 245
Why Prefer HTTP? 247
No Platform Coupling 247
Everyone Understands HTTP 247
Lots of Mature Tooling and Libraries 247
Dogfooding Your APIs 247
RPC 248
Implementing RPC over HTTP 248
SOAP 249
Plain XML or JSON: The Modern Approach to RPC 259
Choosing a Flavor of RPC 263
REST 264
Demystifying REST 264
Resources 264
Hypermedia 265
Statelessness 265
REST Fully Embraces HTTP 266
What REST Is Not 267
REST for Bounded Context Integration 268
Designing for REST 268
Building Event-Driven REST Systems with ASP.NET Web API 273
Maintaining REST Applications 303
Versioning 303
Monitoring and Metrics 303
Drawbacks with REST for Bounded Context Integration 304
Less Fault Tolerance Out of the Box 304
Eventual Consistency 304
The Salient Points 305
PART III: TACTICAL PATTERNS: CREATING EFFECTIVE DOMAIN MODELS
CHAPTER 14: INTRODUCING THE DOMAIN MODELING BUILDING BLOCKS 309
Tactical Patterns 310
Patterns to Model Your Domain 310
Entities 310
Value Objects 314
Domain Services 317
Modules 318
Lifecycle Patterns 318
Aggregates 318
Factories 322
Repositories 323
Emerging Patterns 324
Domain Events 324
Event Sourcing 326
The Salient Points 327
CHAPTER 15: VALUE OBJECTS 329
When to Use a Value Object 330
Representing a Descriptive, Identity-Less Concept 330
Enhancing Explicitness 331
Defining Characteristics 333
Identity-Less 333
Attribute-Based Equality 333
Behavior-Rich 337
Cohesive 337
Immutable 337
Combinable 339
Self-Validating 341
Testable 344
Common Modeling Patterns 345
Static Factory Methods 345
Micro Types (Also Known as Tiny Types) 347
Collection Aversion 349
Persistence 35
NoSQL 352
SQL 353
Flat Denormalization 353
Normalizing into Separate Tables 357
The Salient Points 359
CHAPTER 16: ENTITIES 36
Understanding Entities 362
Domain Concepts with Identity and Continuity 362
Context-Dependent 363
Implementing Entities 363
Assigning Identifiers 363
Natural Keys 363
Arbitrarily Generated IDs 364
Datastore-Generated IDs 368
Pushing Behavior into Value Objects and Domain Services 369
Validating and Enforcing Invariants 371
Focusing on Behavior, Not Data 374
Avoiding the "Model the Real-World" Fallacy 377
Designing for Distribution 378
Common Entity Modeling Principles and Patterns 380
Implementing Validation and Invariants with Specifications 380
Avoid the State Pattern; Use Explicit Modeling 382
Avoiding Getters and Setters with the Memento Pattern 385
Favor Hidden-Side-Effect-Free Functions 386
The Salient Points 388
CHAPTER 17: DOMAIN SERVICES 389
Understanding Domain Services 390
When to Use a Domain Service 390
Encapsulating Business Policies and Processes 390
Representing Contracts 394
Anatomy of a Domain Service 395
Avoiding Anemic Domain Models 395
Contrasting with Application Services 396
Utilizing Domain Services 397
In the Service Layer 397
In the Domain 398
Manually Wiring Up 399
Using Dependency Injection 400
Using a Service Locator 400
Applying Double Dispatch 401
Decoupling with Domain Events 402
Should Entities Even Know About Domain Services? 403
The Salient Points 403
CHAPTER 18: DOMAIN EVENTS 405
Essence of the Domain Events Pattern 406
Important Domain Occurrences That Have Already Happened 406
Reacting to Events 407
Optional Asynchrony 407
Internal vs External Events 408
Event Handling Actions 409
Invoke Domain Logic 409
Invoke Application Logic 410
Domain Events' Implementation Patterns 410
Use the .Net Framework's Events Model 410
Use an In-Memory Bus 412
Udi Dahan's Static DomainEvents Class 415
Handling Threading Issues 417
Avoid a Static Class by Using Method Injection 418
Return Domain Events 419
Use an IoC Container as an Event Dispatcher 421
Testing Domain Events 422
Unit Testing 422
Application Service Layer Testing 424
The Salient Points 425
CHAPTER 19: AGGREGATES 427
Managing Complex Object Graphs 428
Favoring a Single Traversal Direction 428
Qualifying Associations 430
Preferring IDs Over Object References 431
Aggregates 434
Design Around Domain Invariants 435
Higher Level of Domain Abstraction 435
Consistency Boundaries 435
Transactional Consistency Internally 436
Eventual Consistency Externally 439
Special Cases 440
Favor Smaller Aggregates 441
Large Aggregates Can Degrade Performance 441
Large Aggregates Are More Susceptible to Concurrency Conflicts 442
Large Aggregates May Not Scale Well 442
Defining Aggregate Boundaries 442
eBidder: The Online Auction Case Study 443
Aligning with Invariants 444
Aligning with Transactions and Consistency 446
Ignoring User Interface Influences 448
Avoiding Dumb Collections and Containers 448
Don't Focus on HAS-A Relationships 449
Refactoring to Aggregates 449
Satisfying Business Use Cases-Not Real Life 449
Implementing Aggregates 450
Selecting an Aggregate Root 450
Exposing Behavioral Interfaces 452
Protecting Internal State 453
Allowing Only Roots to Have Global Identity 454
Referencing Other Aggregates 454
Nothing Outside An Aggregate's Boundary May Hold a Reference to Anything Inside 455
The Aggregate Root Can Hand Out Transient References to the Internal Domain Objects 456
Objects within the Aggregate Can Hold References to Other Aggregate Roots 456
Implementing Persistence 458
Access to Domain Objects for Reading Can Be at the Database Level 460
A Delete Operation Must Remove Everything within the Aggregate Boundary at Once 461
Avoiding Lazy Loading 461
Implementing Transactional Consistency 462
Implementing Eventual Consistency 463
Rules That Span Multiple Aggregates 463
Asynchronous Eventual Consistency 464
Implementing Concurrency 465
The Salient Points 468
CHAPTER 20: FACTORIES 469
The Role of a Factory 469
Separating Use from Construction 470
Encapsulating Internals 470
Hiding Decisions on Creation Type 472
Factory Methods on Aggregates 474
Factories for Reconstitution 475
Use Factories Pragmatically 477
The Salient Points 477
CHAPTER 21: REPOSITORIES 479
Repositories 479
A Misunderstood Pattern 481
Is the Repository an Antipattern? 481
The Difference between a Domain Model and a Persistence Model 482
The Generic Repository 483
Aggregate Persistence Strategies 486
Using a Persistence Framework That Can Map the Domain Model to the Data Model without Compromise 486
Using a Persistence Framework That Cannot Map the Domain Model Directly without Compromise 487
Public Getters and Setters 487
Using the Memento Pattern 488
Event Streams 49
Be Pragmatic 491
A Repository Is an Explicit Contract 492
Transaction Management and Units of Work 493
To Save or Not To Save 497
Persistence Frameworks That Track Domain Object Changes 497
Having to Explicitly Save Changes to Aggregates 498
The Repository as an Anticorruption Layer 499
Other Responsibilities of a Repository 500
Entity ID Generation 500
Collection Summaries 502
Concurrency 503
Audit Trails 506
Repository Antipatterns 506
Antipatterns: Don't Support Ad Hoc Queries 506
Antipatterns: Lazy Loading Is Design Smell 507
Antipatterns: Don't Use Repositories for Reporting Needs 507
Repository Implementations 508
Persistence Framework Can Map Domain Model to Data Model without Compromise 509
NHibernate Example 509
RavenDB Example 543
Persistence Framework Cannot Map Domain Model Directly without Compromise 557
Entity Framework Example 558
Micro ORM Example 577
The Salient Points 593
CHAPTER 22: EVENT SOURCING 595
The Limitations of Storing State as a Snapshot 596
Gaining Competitive Advantage by Storing State as a Stream of Events 597
Temporal Queries 597
Projections 599
Snapshots 599
Event-Sourced Aggregates 600
Structuring 600
Adding Event-Sourcing Capabilities 601
Exposing Expressive Domain-Focused APIs 602
Adding Snapshot Support 604
Persisting and Rehydrating 605
Creating an Event-Sourcing Repository 605
Adding Snapshot Persistence and Reloading 607
Handling Concurrency 609
Testing 610
Building an Event Store 611
Designing a Storage Format 612
Creating Event Streams 614
Appending to Event Streams 614
Querying Event Streams 615
Adding Snapshot Support 616
Managing Concurrency 618
A SQL Server-Based Event Store 621
Choosing a Schema 621
Creating a Stream 622
Saving Events 623
Loading Events from a Stream 624
Snapshots 625
Is Building Your Own Event Store a Good Idea? 627
Using the Purpose-Built Event Store 627
Installing Greg Young's Event Store 628
Using the C# Client Library 627
Running Temporal Queries 632
Querying a Single Stream 632
Querying Multiple Streams 634
Creating Projections 635
CQRS with Event Sourcing 637
Using Projections to Create View Caches 638
CQRS and Event Sourcing Synergy 638
Event Streams as Queues 639
No Two-Phase Commits 639
Recapping the Benefits of Event Sourcing 639
Competitive Business Advantage 639
Expressive Behavior-Focused Aggregates 639
Simplified Persistence 640
Superior Debugging 640
Weighing the Costs of Event Sourcing 640
Versioning 640
New Concepts to Learn and Skills to Hone 640
New Technologies to Learn and Master 641
Greater Data Storage Requirements 641
Additional Learning Resources 641
The Salient Points 641
PART IV: DESIGN PATTERNS FOR EFFECTIVE APPLICATIONS
CHAPTER 23: ARCHITECTING APPLICATION USER INTERFACES 645
Design Considerations 646
Owned UIs versus Composed UIs 646
Autonomous 646
Authoritative 647
Some Help Deciding 648
HTML APIs versus Data APIs 649
Client versus Server-Side Aggregation/Coordination 649
Example 1: An HTML API-Based, Server-Side UI for Nondistributed Bounded Contexts 651
Example 2: A Data API-Based, Client-Side UI for Distributed Bounded Contexts 658
The Salient Points 667
CHAPTER 24: CQRS: AN ARCHITECTURE OF A BOUNDED CONTEXT 669
The Challenges of Maintaining a Single Model for Two Contexts 670
A Better Architecture for C
WRITING SOFTWARE IS EASY- at least if it's greenfield software. When it comes to modifying code written by other developers or code you wrote six months ago, it can be a bit of a bore at best and a nightmare at worst. The software works, but you aren't sure exactly how. It contains all the right frameworks and patterns, and has been created using an agile approach, but introducing new features into the codebase is harder than it should be. Even business experts aren't helpful because the code bears no resemblance to the language they use. Working on such systems becomes a chore, leaving developers frustrated and devoid of any coding pleasure.
Domain-Driven Design (DDD) is a process that aligns your code with the reality of your problem domain. As your product evolves, adding new features becomes as easy as it was in the good old days of greenfield development. Although DDD understands the need for software patterns, principles, methodologies, and frameworks, it values developers and domain experts working together to understand domain concepts, policies, and logic equally. With a greater knowledge of the problem domain and a synergy with the business, developers are more likely to build software that is more readable and easier to adapt for future enhancement.
Following the DDD philosophy will give developers the knowledge and skills they need to tackle large or complex business systems effectively. Future enhancement requests won't be met with an air of dread, and developers will no longer have stigma attached to the legacy application. In fact, the term legacy will be recategorized in a developer's mind as meaning this: a system that continues to give value for the business.
This book provides a thorough understanding of how you can apply the patterns and practices of DDD on your own projects, but before delving into the details, it's good to take a bird's-eye view of the philosophy so you can get a sense of what DDD is really all about.
Before you can develop a solution, you must understand the problem. DDD emphasizes the need to focus on the business problem domain: its terminology, the core reasons behind why the software is being developed, and what success means to the business. The need for the development team to value domain knowledge just as much as technical expertise is vital to gain a deeper insight into the problem domain and to decompose large domains into smaller subdomains.
Figure I.1 shows a high-level overview of the problem space of DDD that will be introduced in the first part of this book.
FIGURE I.1 A blueprint of the problem space of DDD.
When you have a sound understanding of the problem domain, strategic patterns of DDD can help you implement a technical solution in synergy with the problem space. Patterns enable core parts of your system that are crucial to the success of the product to be protected from the generic areas. Isolating integral components allows them to be modified without having a rippling effect throughout the system.
Core parts of your product that are sufficiently complex or will frequently change should be based on a model. The tactical patterns of DDD along with Model-Driven Design will help you create a useful model of your domain in code. A model is the home to all of the domain logic that enables your application to fulfill business use cases. A model is kept separate from technical complexities to enable business rules and policies to evolve. A model that is in synergy with the problem domain will enable your software to be adaptable and understood by other developers and business experts.
Figure I.2 shows a high-level overview of the solution space of DDD that is introduced in the first part of this book.
FIGURE I.2 A blueprint of the solution space of Domain-Driven Design.
This book is divided into four parts. Part I focuses on the philosophy, principles, and practices of DDD. Part II details the strategic patterns of integrating bounded contexts. Part III covers tactical patterns for creating effective domain models. Part IV delves into design patterns you can apply to utilize the domain model and build effective applications.
Part I introduces you to the principles and practices of DDD.
DDD is a philosophy to help with the challenges of building software for complex domains. This chapter introduces the philosophy and explains why language, collaboration, and context are the most important facets of DDD and why it is much more than a collection of coding patterns.
Making sense of a complex problem domain is essential to creating maintainable software. Knowledge crunching with domain experts is key to unlocking that knowledge. Chapter 2 details techniques to enable development teams to collaborate, experiment, and learn with domain experts to create an effective domain model.
Chapter 3 explains how to distill large problem domains and identify the most important part of a problem: the core domain. It then explains why you should focus time and energy in the core domain and isolate it from the less important supporting and generic domains.
Business colleagues understand an analysis model based on the problem area you are working within. Development teams have their own code version of this model. In order for business and technical teams to collaborate a single model is needed. A ubiquitous language and a shared understanding of the problem space is what binds the analysis model to the code model. The idea of a shared language is core to DDD and underpins the philosophy. A language describing the terms and concepts of the domain, which is created by both the development team and the business experts, is vital to aid communication on complex systems.
Chapter 5 expands on the role of the domain model within your application and the responsibilities it takes on. The chapter also presents the various patterns that can be used to implement a domain model and what situations they are most appropriate for.
In large solutions more than a single model may exist. It is important to protect the integrity of each model to remove the chance of ambiguity in the language and concepts being reused inappropriately by different teams. The strategic pattern known as bounded context is designed to isolate and protect a model in a context while ensuring it can collaborate with other models.
Using a context map to understand the relationships between different models in an application and how they integrate is vital for strategic design. It is not only the technical integrations that context maps cover but also the political relationships between teams. Context maps provide a view of the landscape that can help teams understand their model in the context of the entire landscape.
An application needs to be able to utilize the domain model to satisfy business use cases. Chapter 8 introduces architectural patterns to structure your applications to retain the integrity of your domain model.
Chapter 9 describes the common issues teams face when applying DDD and why it's important to know when not to use it. The chapter also focuses on why applying DDD to simple problems can lead to overdesigned systems and needless complexity.
Chapter 10 covers techniques to sell DDD and to start applying the principles and practices to your projects. It explains how exploration and experimentation are more useful to build great software than trying to create the perfect domain model.
Part II shows you how to integrate bounded contexts, and offers details on the options open for architecting bounded contexts. Code examples are presented that detail how to integrate with legacy applications. Also included are techniques for communicating across bounded contexts.
Modern software applications are distributed systems that have scalability and reliability requirements. This chapter blends distributed systems theory with DDD so that you can have the best of both worlds.
A sample application is built showing how to apply distributed systems principles synergistically with DDD using a message bus for asynchronous messaging.
Another sample application is built showing an alternative approach to building asynchronous distributed systems. This approach uses standard protocols like Hypertext Transport Protocol (HTTP), REST, and Atom instead of a message...
Dateiformat: ePUBKopierschutz: Adobe-DRM (Digital Rights Management)
Systemvoraussetzungen:
Das Dateiformat ePUB ist sehr gut für Romane und Sachbücher geeignet – also für „fließenden” Text ohne komplexes Layout. Bei E-Readern oder Smartphones passt sich der Zeilen- und Seitenumbruch automatisch den kleinen Displays an. Mit Adobe-DRM wird hier ein „harter” Kopierschutz verwendet. Wenn die notwendigen Voraussetzungen nicht vorliegen, können Sie das E-Book leider nicht öffnen. Daher müssen Sie bereits vor dem Download Ihre Lese-Hardware vorbereiten.Bitte beachten Sie: Wir empfehlen Ihnen unbedingt nach Installation der Lese-Software diese mit Ihrer persönlichen Adobe-ID zu autorisieren!
Weitere Informationen finden Sie in unserer E-Book Hilfe.
