Applying Domain-Driven Design and Patterns With Examples in C# and .NET

by Nilsson, Jimmy

• ISBN13: 9780321268204
• ISBN10: 0321268202
• Edition: 1st
• Format: Hardcover
• Copyright: 2006-05-08
• Publisher: Addison-Wesley Professional

Summary

"[This] is a book about design in the .NET world, driven in an agile manner and infused with the products of the enterprise patterns community. [It] shows you how to begin applying such things as TDD, object relational mapping, and DDD to .NET projects...techniques that many developers think are the key to future software development.... As the technology gets more capable and sophisticated, it becomes more important to understand how to use it well. This book is a valuable step toward advancing that understanding." Martin Fowler, AUTHOR of Refactoring and Patterns of Enterprise Application Architecture Patterns, Domain-Driven Design (DDD), and Test-Driven Development (TDD) enable architects and developers to create systems that are powerful, robust, and maintainable. Now, therers"s a comprehensive, practical guide to leveraging all these techniques primarily in Microsoft .NET environments, but the discussions are just as useful for Java developers. Drawing on seminal work by Martin Fowler (Patterns of Enterprise Application Architecture) and Eric Evans (Domain-Driven Design), Jimmy Nilsson shows how to create real-world architectures for any .NET application. Nilsson illuminates each principle with clear, well-annotated code examples based on C# 1.1 and 2.0. His examples and discussions will be valuable both to C# developers and those working with other .NET languages and any databaseseven with other platforms, such as J2EE. Coverage includes Quick primers on patterns, TDD, and refactoring Using architectural techniques to improve software quality Using domain models to support business rules and validation Applying enterprise patterns to provide persistence support via NHibernate Planning effectively for the presentation layer and UI testing Designing for DepENDency Injection, Aspect Orientation, and other new paradigms

Author Biography

Jimmy Nilsson owns and runs the Swedish consulting company JNSK AB. He has written numerous technical articles and two books. He has also been training and speaking at conferences, but above everything else, he is a developer with almost 20 years of experience (www.jnsk.se/weblog/).

Table of Contents

About the Author	xxv
Forewords	xxvii
Preface: Bridging Gaps	xxxi
Part I: Background	1	(110)
Values to Value	3	(44)
Overall Values	3	(1)
Architecture Styles to Value	4	(24)
Focus on the Model	4	(1)
Use Case Focus	5	(4)
If You Have a Model Focus, Use the Domain Model Pattern	9	(5)
Handle the Database with Care	14	(5)
The Impedance Mismatch Between Domain Model and Relational Database	19	(5)
Handle Distribution with Care	24	(2)
Messaging Focus	26	(2)
Process Ingredients to Value	28	(12)
Up-Front Architecture Design	29	(3)
Domain-Driven Design	32	(1)
Test-Driven Development	33	(4)
Refactoring	37	(2)
Which Ingredient or a Combination?	39	(1)
Continuous Integration	40	(2)
The Integration Problem	40	(1)
The Solution (Or at Least a Big Step in the Right Direction)	41	(1)
Lessons Learned in My Organization	41	(1)
Further Information	42	(1)
Don't Forget About Operations	42	(3)
An Example of When a Mechanism Is Needed	42	(2)
Some Examples of Operational Mechanisms	44	(1)
It's Not Just Our Fault	45	(1)
Summary	45	(2)
A Head Start on Patterns	47	(30)
A Little Bit About Patterns	48	(4)
Why Learn About Patterns?	48	(2)
Is There Something to Look Out for Regarding Patterns?	50	(2)
Design Patterns	52	(8)
An Example: State Pattern	53	(7)
Architectural Patterns	60	(2)
An Example: Layers	61	(1)
Another Example: Domain Model Pattern	62	(1)
Design Patterns for Specific Types of Applications	62	(7)
An Example: Query Objects	63	(6)
Domain Patterns	69	(6)
An Example: Factory	70	(5)
Summary	75	(2)
TDD and Refactoring	77	(34)
Test-Driven Development (TDD)	77	(13)
The TDD Flow	78	(1)
Time for a Demo	78	(7)
Design Effects	85	(3)
Problems	88	(2)
The Next Phase?	90	(1)
Mocks and Stubs	90	(8)
A Typical Unit Test	90	(1)
Declaration of Independence	91	(1)
Working with Difficult Team Members	92	(1)
Replacing Collaborators with Testing Stubs	93	(2)
Replacing Collaborators with Mock Objects	95	(2)
Design Implications	97	(1)
Consequences	98	(1)
Further Information	98	(1)
Refactoring	98	(12)
Let's Clean Some Smelly Code	99	(11)
Summary	110	(1)
Part II: Applying DDD	111	(166)
A New Default Architecture	113	(30)
The Basis of the New Default Architecture	113	(4)
From Database Focus to Domain Model Focus	115	(1)
More Specifically, a DDD Focus	115	(1)
Layering According to DDD	116	(1)
A First Sketch	117	(17)
Problems/Features for Domain Model Example	118	(2)
Dealing with Features One by One	120	(12)
The Domain Model to This Point	132	(2)
Making a First Attempt at Hooking the UI to the Domain Model	134	(4)
A Basic Goal	134	(1)
The Current Focus of the Simple UI	135	(1)
List Orders for a Customer	135	(1)
Add an Order	136	(1)
What Did We Just See?	137	(1)
Yet Another Dimension	138	(4)
Location of the Domain Model	139	(1)
Isolating or Sharing Instances	140	(1)
Stateful or Stateless Domain Model Instantiation	141	(1)
Complete or Subset Instantiation of the Domain Model	141	(1)
Summary	142	(1)
Moving Further with Domain-Driven Design	143	(38)
Refining the Domain Model Through Simple TDD Experimentation	143	(36)
Starting with the Creation of Order and OrderFactory	144	(4)
Some Domain Logic	148	(2)
Second Task: The OrderRepository + OrderNumber	150	(5)
Reconstituting an Entity from Persistence: How to Set Values from the Outside	155	(5)
Fetching a List of Orders	160	(1)
It's Time to Talk About Entities	161	(1)
Back to the Flow Again	162	(1)
The Bird's-Eye View	163	(2)
Faking the OrderRepository	165	(2)
A Few Words About Saving	167	(1)
Total Amount for Each Order	167	(5)
Historic Customer Information	172	(3)
The Life Cycle of an Instance	175	(1)
Type of Order	176	(1)
Reference Person for an Order	177	(2)
Fluent Interface	179	(1)
Summary	180	(1)
Preparing for Infrastructure	181	(48)
POCO as a Lifestyle	182	(16)
PI for Our Entities and Value Objects	183	(5)
PI or not PI?	188	(1)
Runtime Versus Compile Time PI	188	(1)
The Cost for PI Entities/Value Objects	189	(2)
PI for Our Repositories	191	(6)
The Cost for Single-Set Repositories	197	(1)
Dealing with Save Scenarios	198	(5)
Reasons for the Decisions	199	(4)
Let's Build the Fake Mechanism	203	(8)
More Features of the Fake Mechanism	204	(1)
The Implementation of the Fake	205	(2)
Affecting the Unit Tests	207	(4)
Database Testing	211	(8)
Reset the Database Before Each Test	212	(2)
Maintain the State of the Database During the Run	214	(1)
Reset the Data Used by a Test Before the Test	214	(1)
Don't Forget Your Evolving Schema!	215	(1)
Separate the Testing of the Unit from the Testing of the Call to the Database	216	(3)
Querying	219	(9)
Single-Set of Query Objects	220	(2)
The Cost for Single-Set of Query Objects	222	(2)
Where to Locate Queries	224	(1)
Aggregates as a Tool Again	225	(2)
Specifications as Queries	227	(1)
Other Querying Alternatives	228	(1)
Summary	228	(1)
Let the Rules Rule	229	(48)
Categorization of Rules	229	(1)
Principles for Rules and Their Usage	230	(2)
Two-Way Rules Checking: Optional (Possible) to Check Proactively, Mandatory (and Automatic) to Check Reactively	230	(1)
All States, Even When in Error, Should be Savable	230	(1)
Rules Should Be Productive to Use	231	(1)
Rules Should Optionally be Configurable so that You Can Add Custom Rules	231	(1)
Rules Should Be Located with State	231	(1)
Rules Should Be Extremely Testable	232	(1)
The System Should Stop You from Getting into a Bad State	232	(1)
Starting to Create an API	232	(6)
Context, Context, Context!	234	(1)
Database Constraints	234	(1)
Bind Rules to Transitions Related to the Domain or the Infrastructure?	235	(1)
Refining the Principle: ``All States, Even when in Error, Should Be Savable''	236	(2)
Requirements for a Basic Rules API Related to Persistence	238	(3)
Back to the Found API Problems	239	(1)
What Was the Problem?	240	(1)
We Allowed an Incorrect Transition	240	(1)
What If We Forgot to Check?	241	(1)
Focus on Domain-Related Rules	241	(13)
Rules that Require Cooperation	243	(2)
Locating Set-Based Processing Methods	245	(2)
Service-Serviced Validation	247	(1)
Trying to Transition when We Shouldn't	247	(2)
Business ID	249	(3)
Avoiding Problems	252	(1)
Aggregates as the Tool Again	253	(1)
Extending the API	254	(1)
Ask for Rules to Be Used to Set Up UI	254	(1)
Make It Possible to Inject Rules	254	(1)
Refining the Implementation	255	(15)
A Native Implementation	255	(6)
Creating Rule Classes---Leaving the Most Native Stage	261	(3)
Setting Up a List of Rules	264	(1)
Using the List of Rules	264	(1)
Dealing with Sublists	265	(1)
An API Improvement	266	(1)
Customization	267	(1)
Providing the Consumer with Metadata	268	(1)
A Problem Suitable for a Pattern?	269	(1)
What About the Complex Rules?	269	(1)
Binding to the Persistence Abstraction	270	(3)
Make the Validation Interface Pluggable	270	(1)
Alternative Solution for Approaching the Reactive Validation on Save	271	(1)
Reuse Mapping Metadata	272	(1)
Generics and Anonymous Methods to the Rescue	273	(2)
What Other Have Done	275	(1)
Summary	275	(2)
Part III: Applying PoEAA	277	(70)
Infrastructure for Persistence	279	(32)
Requirements on the Persistence Infrastructure	280	(2)
Where to Store Data	282	(6)
RAM	282	(3)
File System	285	(1)
Object Database	285	(2)
Relational Database	287	(1)
One or Several Resource Managers?	287	(1)
Other Factors	288	(1)
Choose and Move On	288	(1)
Approach	288	(6)
Custom Manual Code	289	(1)
Code Generation of Custom Code	290	(1)
Metadata Mapping (Object Relational (O/R) Mapper)	291	(2)
Choosing Again	293	(1)
Classification	294	(7)
Domain Model Style	294	(1)
Mapper Style	295	(1)
Starting Point	295	(2)
API Focus	297	(1)
Query Language Style	297	(1)
Advanced Database Support	298	(2)
Other Functionality	300	(1)
Another Classification: Infrastructure Patterns	301	(8)
Metadata Mapping: Type of Metadata	301	(1)
Identity Field	302	(2)
Foreign Key Mapping	304	(1)
Embedded Value	305	(1)
Inheritance Solutions	305	(1)
Identity Map	306	(1)
Unit of Work	307	(1)
Lazy Load/Eager Load	307	(1)
Controlling Concurrency	308	(1)
Summary	309	(2)
Putting NHibernate into Action	311	(36)
Why NHibernate?	311	(1)
A Short Introduction to NHibernate	312	(11)
Preparations	312	(2)
Some Mapping Metadata	314	(6)
A Tiny API Example	320	(2)
Transactions	322	(1)
Requirements of the Persistence Infrastructure	323	(5)
High Level of Persistent Ignorant	323	(1)
Certain Desirable Features for the Life Cycle of the Persistent Entities	324	(2)
Deal Carefully with the Relational Database	326	(2)
Classification	328	(7)
Domain Model Style	328	(1)
Mapper Style	328	(1)
Starting Point	329	(1)
API Focus	330	(1)
Query Language Style	330	(1)
Advanced Database Support	331	(2)
Other Functionality	333	(2)
Another Classification: Infrastructure Patterns	335	(7)
Metadata Mapping: Type of Metadata	335	(1)
Identity Field	335	(2)
Foreign Key Mapping	337	(1)
Embedded Value	337	(1)
Inheritance Solutions	338	(2)
Identity Map	340	(1)
Unit of Work	340	(1)
Lazy Load/Eager Load	340	(1)
Controlling Concurrency	341	(1)
Bonus: Validation Hooks	342	(1)
NHibernate and DDD	342	(3)
Overview of the Assemblies	343	(1)
ISession and Repositories	343	(1)
ISession, Repositories, and Transactions	344	(1)
What Did We Gain?	344	(1)
Summary	345	(2)
Part IV: What's Next?	347	(98)
Design Techniques to Embrace	349	(58)
Context Is King	350	(4)
Layers and Partitions	350	(1)
Reasons for Partitioning	351	(1)
Bounded Context	352	(1)
How Do Bounded Contexts and Partitions Relate?	353	(1)
Scaling up DDD Projects	353	(1)
Why Partition a Domain Model---So?	353	(1)
An Introduction to SOA	354	(14)
So What Is SOA Anyway?	354	(1)
Why Do We Need SOA?	354	(1)
How Is SOA Different?	355	(1)
What Is a Service?	355	(1)
What Goes in a Service?	356	(1)
Where Do the Four Tenets Lead Me?	357	(1)
What Is a Service? Take 2	358	(1)
The Place of OO in SOA	359	(1)
Client-Server and SOA	359	(1)
One-Way Asynchronous Messaging	360	(1)
How SOA Improves Scalability	361	(1)
The Design of a SOA Service	361	(1)
How Would a Service Interact with Other Services?	362	(3)
SOA and Unavailable Services	365	(1)
Complex Messaging Processes	366	(1)
Scaling Services	367	(1)
Summary	367	(1)
Inversion of Control and Dependency Injection	368	(18)
No Object Is an Island	368	(2)
Factories, Registries, and Service Locators	370	(3)
Constructor Dependency Injection	373	(3)
Setter Dependency Injection	376	(1)
Inversion of Control	377	(1)
Dependency Injection with the Spring.NET Framework	378	(2)
Auto-Wiring with PicoContainer.NET	380	(2)
Nested Containers	382	(2)
Service Locator Versus Dependency Injection	384	(1)
Summary	385	(1)
Aspect-Oriented Programming (AOP)	386	(19)
What Is the Buzz About?	387	(3)
AOP Terminology Defined	390	(1)
AOP in .NET	391	(13)
Summary	404	(1)
Summary	405	(2)
Focus on the UI	407	(38)
A Prepilogue	407	(2)
The Model-View-Controller Pattern	409	(10)
Example: Joe's Shoe Shop	410	(6)
Simplifying the View Interfaces Through Adapters	416	(1)
Decouple the Controller from the View	417	(1)
Combining Views/Controllers	417	(1)
Is It Worth It?	418	(1)
Test-Driving a Web Form	419	(12)
Background	419	(1)
An Example	419	(1)
Domain Model	420	(1)
TDD of GUI	421	(6)
The Web Form Implementation	427	(2)
Summary	429	(1)
Mocking with NMock	429	(2)
Mapping and Wrapping	431	(12)
Mapping and Wrapping	432	(1)
Wrapping the Domain Model with the Presentation Model	433	(1)
Mapping the Presentation Model to Domain Model	434	(3)
Managing Relationships	437	(3)
Matters of State	440	(2)
Final Thoughts	442	(1)
Summary	443	(1)
Epilogue	443	(2)
Part V: Appendices	445	(2)
Appendix A: Other Domain Model Styles	447	(36)
Object-Oriented Data Model, Smart Service Layer, and Documents	449	(12)
In the Beginning	449	(1)
Object-Orientation and Relational Data Structures	450	(1)
The Domain Model and Object-Relational Mapping	450	(1)
Service Layer	451	(1)
Combining Things	452	(1)
Jimmy's Application and SOA	453	(2)
Service Layer Design	455	(2)
Submitting Data	457	(2)
How Fine-Grained?	459	(1)
A Few Words About Transactions	460	(1)
Summary	461	(1)
The Database Model Is the Domain Model	461	(8)
The Entity's Habitat	462	(4)
Functional Research as the Application Foundation	466	(3)
Pragmatism and the Nontraditional Approach	469	(13)
Background and History	470	(1)
Overview of the Architecture	470	(5)
Jimmy's Order Application Exercise	475	(7)
Some Final Points	482	(1)
Summary	482	(1)
Appendix B: Catalog of Discussed Patterns	483	(10)
References	493	(8)
Index	501

Excerpts

Preface: Bridging Gaps Preface: Bridging GapsOn the cover of this book is a picture of the Oslash;resund Bridge that connects Sweden and Denmark. It seems that all software architecture books must have a bridge on the cover, but there are some additional reasons the bridge is appropriate for this book.This bridge replaced a ferry that I took many times as a child. I enjoy very much driving over it even after dozens of times.On a personal note, my father was on the team that built the highest parts of the bridge.But beyond these, the main reason is that this book is very much about bridging gaps; bridging gaps between users and developers; bridging gaps between business and software; bridging gaps between logic and storage. Bridging gaps between "DB-guys" and "OO-guys"...I will refrain from making a joke about the Bridge pattern GoF Design -Patterns. Hey, how geeky can a preface be? Focus of This BookThe main focus of the book is how a Domain Model could be constructed to be clean, yet still be persistence-friendly. It shows what the persistence solution could look like for such a Domain Model and especially how to bridge that gap between the Domain Model and the database.Put another way, my vision has been to provide a book that will put Eric Evans' Domain-Driven Design Evans DDD and Martin Fowler's Patterns of Enterprise Application Architecture Fowler PoEAA in context.DDD might be perceived as a bit abstract. Therefore, more concrete examples are helpful regarding persistence, for example. Mine may be fairly basic, but it is a platform to start from. This book not only explains how to use the patterns, but also how the patterns are used in O/R Mappers, for example.It has become very clear to me that "one size does not fit all" when it comes to architecture. Having said that, patterns have proven to be general enough to use and reuse in context after context.The focus isn't on the patterns themselves, but this book uses patterns in every chapter as a tool and language for discussing different design aspects. A nice side effect is that patterns-ignorant readers will also gain some insight and interest into patterns along the way.That also goes for TDD. Not all developers have become interested in this yet. I think it's especially common in the .NET community that TDD (just as patterns) is considered a niche technique at best, or it might even be totally unknown. Readers will learn how to apply TDD. Why This Book?Writing my first book Nilsson NED was a really tough project on top of all my other ordinary projects and obligations. I was pretty sure I wouldn't write another, but the time came when I thought I had something to say that I couldn't leave unsaid.My change of heart started when I read two recent books that inspired me and changed my thinking. First, there was Martin Fowler's Patterns of Enterprise Application Architecture Fowler PoEAA. This book inspired me to give the Domain Model pattern another try after having failed with several earlier attempts.Then I read Eric Evans' book Domain-Driven Design Evans DDD. This book provided me with insights about how to think and act regarding development with a strong domain focus and with a certain style of how to apply the Domain Model pattern.Another important influence was all that I learned from teaching my patterns course over a couple of years. As I interacted with students and the material evolved, I had insights myself.My views of DDD transformed as I worked on an ambitious (though unfortunately unfinished) open source project called Valhalla, which I developed in collaboration with Christoffer Skjoldborg. (Christoffer did by far the most work.)To summarize all this