2006 aw applying domain driven design and patterns wit

Applying Domain-Driven Design and Patterns: With Examples in C# and .NET, 1/eBy Jimmy Nilsson.... This book is a valuable step toward advancing that understanding." Martin Fowler, author

Applying Domain-Driven Design and Patterns: With Examples in C# and NET, 1/e

By Jimmy Nilsson

Publisher: Addison Wesley Professional Pub Date: May 08, 2006

Print ISBN-10: 0-321-26820-2 Print ISBN-13: 978-0-321-26820-4 Pages: 576

Table of Contents | Index

"[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, there'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

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

· Designing for Dependency Injection, Aspect Orientation, and other new paradigms

Applying Domain-Driven Design and Patterns: With Examples in C# and NET, 1/e

By Jimmy Nilsson

Publisher: Addison Wesley Professional Pub Date: May 08, 2006

Print ISBN-10: 0-321-26820-2 Print ISBN-13: 978-0-321-26820-4 Pages: 576

Summary

Chapter 5 Moving Further with Domain-Driven Design

Refining the Domain Model Through Simple TDD Experimentation Fluent Interface

Single Table Inheritance [Fowler PoEAA] Singleton [GoF Design Patterns]

Specification [Evans DDD]

State [GoF Design Patterns]

Table Module [Fowler PoEAA]

Template Method [GoF Design Patterns] Transaction Script [Fowler PoEAA] Unit of Work [Fowler PoEAA]

Value Object [Evans DDD]

References

Index

Many of the designations used by manufacturers and sellers todistinguish their products are claimed as trademarks Wherethose designations appear in this book, and the publisher wasaware of a trademark claim, the designations have been printedwith initial capital letters or in all capitals

The author and publisher have taken care in the preparation ofthis book, but make no expressed or implied warranty of anykind and assume no responsibility for errors or omissions Noliability is assumed for incidental or consequential damages inconnection with or arising out of the use of the information orprograms contained herein

The publisher offers excellent discounts on this book when

ordered in quantity for bulk purchases or special sales, whichmay include electronic versions and/or custom covers and

content particular to your business, training goals, marketingfocus, and branding interests For more information, please

To Lotta, Tim, and Leo: the centers of my universe.

Design and Patterns

"I don't know what it was I professed to doing before I had added Domain-Driven Design and Test-Driven

Development to my toolkit, but from my present

perspective, I'm reticent to call it anything but chaotic hacking Domain-Driven Design and Test-Driven

Development are two approaches that have consistently guided me toward a practical application of software

design principles, and brought my projects to fruition with healthy, sustainable software This is a book that puts its money where its mouth is in terms of concretely

communicating Agile software development practice It's potentially one of the most impactful guides to software development success practices yet offered to the NET software development community."

Scott Bellware, Microsoft MVP for C#, DDD and TDD

Blogger

"Jimmy Nilsson does his readers a great service by

showing them how to apply the foundational principles of enterprise application design and development taught by Evans, Fowler, and other thought leaders The book uses

Jack Greenfield, Enterprise Tools architect, Visual Studio

"Good software architects reserve the right to get

smarter Beyond the goal of shipping their current system, they're on a quest to discover better ways to design and build software This book is travelogue of sorts in which Jimmy documents his journey through a wide range of patterns, practices, and technologies, explaining how his thinking about enterprise systems has evolved along the way If you're traveling the same road, this book is a good companion."

Tim Ewald, principal architect at Foliage Software Systems

and author of Transactional COM+: Building Scalable

Applications

"This book does an excellent job at making tangible the large but very important ideas of Domain-Driven Design."

Floyd Marinescu, author of EJB Design Patterns and

creator of InfoQ.com and TheServerSide.com

"Understanding the concepts and driving forces in the

problem domain is paramount to the success of software development Jimmy Nilsson has drawn inspiration from the past ten years of studies into patterns and Domain- Driven Design as well as recorded his own experiences from concrete development projects This book contains compelling examples of how theory can be translated into practice It demonstrates the author's profound

understanding of design choices and trade-offs involved in object-oriented development."

Anders Hessellund, IT University of Copenhagen, Denmark

"This book tackles an area that is a challenge for most developers on the NET platform As the patterns and

around enterprise guidance for NET, I know how

important this area is for our customers, and am painfully aware of the gaps that still exist in our guidance.

"I was thrilled to see Jimmy would be sharing his insights based on his experience doing DDD and TDD I believe this topic can be best tackled at this point in time through

a focus on simplicity, patterns, and awareness of the

social aspects of building applications.

"I trust Jimmy's experience and knowledge of NET, and have enjoyed his style of sharing concepts and stories I can hardly imagine someone better suited to explain this topic on the platform I work on every day.

"I will definitively recommend Jimmy's book to my

customers, my team, and other Microsoft engineers.

"Ultimately, I hope that our industry can get better at

expressing rich concepts in code, and that it gets better at the social process of articulating and evolving shared

knowledge TDD and DDD lie together at the heart of this path."

advocated in Domain-Driven Design; it is relentlessly

practical, gives the reader insight into the thought process that underlies applying proven techniques and

technologies, and, like all of Jimmy's work, is an easy read

Christian Crowhurst, analyst developer

"I've been working on a joint project with Jimmy for 18 months now Jimmy really lives as he preaches In this book he tells you how he is working in practice He uses O/R Mapping and NHibernate daily and he also really uses TDD to help understand and distill the customer's business logic and to make sure that he only delivers tested, high- quality code Just as he delivers a high-quality book

pattern implementer alike In fact, any developer or

architect who wants to improve the way he/she designs and implements software solutions should read this book."

Per-Ola Nilsson, head of development and software

architect for Luvit

"Constantly abreast with the latest trends in software

development but never swept away by the hype, Jimmy expertly extracts the value and leaves the fluff behind Always humble and with both his ears wide open, he is uniquely well suited to guide and enlighten the reader

using the practical applicability as the standard, shunning the ivory tower Jimmy doesn't offer his help from above

he actually manages to convince us that we have just

learned about the cutting edge from a peer."

www.matshelander.com

"As with Jimmy's previous book, this book is a true

masterpiece: a well-laid out balance between pragmatic software engineering and deep theory."

Frans Bouma, creator of LLBLGen Pro,

weblogs.asp.net/fbouma

"With this book being based on solid ground, Jimmy

tackles the real issues in applying Domain-Driven Design practices Finally we have a manual to keep us from

Martin Rosén-Lidholm, software architect for Exense

Healthcare

"Do you want to build a high-quality enterprise system with object orientation and a relational database? Don't miss this one Jimmy shows you how Test-Driven

Development can be the driving force throughout the

whole project He shows how to map the OO design to the

database, a step often treated very briefly in literature, which alone makes the book worth the money There are also plenty of design tips and discussions so you can

follow his reasoning."

Ingemar Lundberg, passionate software developer,

www.ingolundberg.com

"This important and timely book is a must read for anyone wanting to get into Domain-Driven Design in C#."

Gregory Young, Microsoft MVP for C#, independent

consultant

"This book deals with several important concepts used in modern software development, such as Test-Driven

Development, refactoring, patterns, and of course,

Domain-Driven Design Jimmy Nilsson writes about these things in a very conversational tone, and you almost get the feeling that he is actually sitting next to you, showing you his examples and having a conversation about the pros and cons of different solutions with you personally."

Niclas Nilsson, software developer and educator for

Activa; not a brother to Jimmy, not even related

"This book does an excellent job of bringing Domain-Driven Design (DDD) into practical context by bridging the gaps between different abstraction levels starting from the business perspective down to the system level The book

is ideal for software architects and developers because it

is written in a way that allows it to be used as a primer or reference The author excels in presenting all aspects of DDD in a way that is not only educational but also fun to read."

Gunther Lenz, program manager and author

"Not so very long ago, I blogged about my overall feeling that as architects we may be failing to provide enough guidance for developers to sort through the hundreds of different ways to build software There are many ideas out there that are excellent by themselves and come with

perfectly well-reasoned justifications, working examples, and an impassioned community of believers Very few of them can be used by themselves to build applications, much less systems of applications and services This

leaves it up to developers to find ways to put the

individual ideas together into applications This is always much harder in reality than the proponents of any

particular approach, like to think about Developers, on the other hand, need to get some work done and often don't care to wade through all this every time they start a new application This is true even when they are truly

interested in the potential gains of new approaches or

ideas Jimmy's book is pointed directly at this problem How do you apply some of the great ideas that have come forward in the last few years to real, live development? I think this book does a great job of both explaining the underlying ideas with enough detail to make them

practical and putting the group of ideas together in a way that will help developers see a path from start to end.

Domain-Driven Design, Test-Driven Development,

Dependency Injection, persistence, and many other

practical issues are covered After reading this book, I think a reader will really be able to take these important ideas and use them together effectively Considering the great value of the individual ideas presented, but the

limited numbers of examples of people really using them, this work represents a great win for us all I highly

recommend it."

Philip Nelson, chief scientist for PAi,

xcskiwinn.org/community/blogs/ panmanphil/default.aspx

deeper realization of OOP found in Domain-Driven Design, Test-Driven Development, object/relational persistence, and other Agile methods and patterns can be an arduous and disorienting undertaking for the uninitiated.

"With a patient, pragmatic, and mentoring style, Jimmy takes the reader along for the leap, exploring the issues and the options, giving sound advice along the way This book shows you how to integrate the various methods and patterns into a fully coherent approach to designing and creating superbly maintainable Net software."

George Hicks, senior developer for Property Works

"If you have ever read his blog, you already know that Jimmy Nilsson likes to challenge established 'truths' in the NET community, looking for better ways to design

software He acknowledges that software design is hard, and that one-size-fits-all solutions do not work; pros and cons have to be balanced in context of the problem at

approachable, especially considering all the ground that is covered Because he is on top of the DDD stuff, Jimmy (and friends) brings you distilled knowledge on, and

references to, many of the most valuable techniques and resources within software development today I believe this book to be a valuable guide to applying DDD, and for developers who want to improve their general design

skills."

"In Applying Domain-Driven Design and Patterns, Jimmy Nilsson strengthens his position as an authority on applied software architecture With a nice blend of his personal thoughts on the subjects, Jimmy takes the reader on a tour through most of the modern must-know design

Mikael Freidlitz, vice president of Content and KnowledgePrograms at IASA

"Domain-Driven Design is an important technique that can help produce quality business applications that evolve with the needs of the business In an ideal world, practicing DDD would be about OO designbut in reality, the

technologies we work with impose numerous constraints.

"This book tackles that challenge head on, bridging the gap between DDD concepts and the action of translating them into practice on the NET platform Jimmy not only has a deep understanding of DDD and enterprise

technologies, but has learned many lessons from his

extensive industry experience, and takes a refreshingly pragmatic approach This is a valuable book."

explained, and shown in relevant contexts These will give you a great foundation when you are working with your own Domain Model-based system Both the actual

development techniques as well as practical work methods (as incorporation of Test-Driven Development) are

Leo, son, four years old

"Dad, do you really think someone will read it?"

Tim, son, eight years old

Jimmy Nilsson owns and runs the Swedish consulting

company JNSK AB He has written numerous technical articlesand two books He has also been training and speaking atconferences, but above everything else, he is a developer withalmost 20 years of experience (www.jnsk.se/weblog/)

Building enterprise software is rarely easy Although we have aplethora of tools and frameworks to make it easier, we still have

to figure out how to use these tools well There are lots of

approaches you can take, but the trick is knowing which one touse in specific situationshardly ever does one approach work inall cases Over the last few years there's grown up a community

of people looking to capture approaches to design enterpriseapplications and document them in the form of patterns (I keep

an overview with links at

http://martinfowler.com/articles/enterprisePatterns.html)

People involved in this effort, such as me, try to find commonapproaches and describe how to do them well and when theyare applicable The resulting work is pretty wide ranging, andthat can lead to too much choice for the reader

When I started writing Patterns of Enterprise Application

Architecture (Addison-Wesley, 2002), I looked for this kind of

design advice in the Microsoft world I struggled to find much ofanything, but one rare book that tackled the territory was

Jimmy's earlier book I liked his informal writing style and

eagerness to dig into concepts that many others skimmed over

So it's fitting that Jimmy decided to take many of the ideas

from me and the others in the enterprise patterns communityand show how you can apply them in writing NET applications

The focus of this enterprise patterns community is documentinggood designs, but another thread runs through us We are alsobig fans of agile methods, embracing techniques such as Test-Driven Development (TDD) and refactoring So Jimmy also

brought these ideas into this book Many people think that

pattern-people's focus on design and TDD's focus on evolutionare at odds The huge overlap between pattern-people and

TDDers shows this isn't true, and Jimmy has weaved both of

The result is a book about design in the NET world, driven in anagile manner and infused with the products of the enterprisepatterns community It's a book that shows you how to beginapplying such things as TDD, object-relational mapping, anddomain-driven design to NET projects If you haven't yet comeacross these concepts, you'll find that this book is an

introduction to techniques that many developers think are thekey for future software development If you are familiar withthese ideas, the book will help you pass those ideas on to yourcolleagues

Many people feel the Microsoft community has not been as good

as others in propagating good design advice for enterprise

applications As the technology becomes more capable and

sophisticated, it becomes more important to understand how touse it well This book is a valuable step in advancing that

This book does not push a new grand scheme It unaffectedlyreports on one expert practitioner's use of and combination ofthe current practices he has been drawn to

Jimmy Nilsson reiterates what many of us have been saying:that several currently trendy topicsspecifically, DDD, Patterns ofEnterprise Application Architecture (PoEAA), and Test-DrivenDevelopment (TDD)are not alternatives to each other, but aremutually reinforcing elements of successful development

Effective design is not just a bunch of techniques to be learned

by rote; it is a way of thinking As Jimmy dives into an example

he gives us a little window into his mind He not only shows hissolution and explains it, he lets us see how he got there

When I am designing something, dozens of considerations flitthrough my mind If they are factors I've dealt with often, theypass so quickly I am barely conscious of them If they are inareas where I have less confidence, I dwell on them more Ipresume this is typical of designers, but it is difficult to

communicate to another person As Jimmy walks through hisexamples, it is as if he were slowing this process down to anobservable pace At every little juncture, three or four

alternatives present themselves and get weighed and rejected

in favor of the one he eventually chooses

For example, we want model objects that are implemented free

of entanglement with the persistence technology So what areeight ways (eight!) that a persistence framework can force you

to contaminate the implementation of a domain object? Whatconsiderations would lead you to compromise on some of thesepoints? What do the currently popular frameworks, includingthe NET platform, impose?

Jimmy thinks pragmatically He draws on his experience to

make a design choice that will likely take him toward the goal,adhering to the deeper design principle, rather than the choicethat looks the most like a textbook example And all of his

decisions are provisional

The first design principle Jimmy holds in front of himself is thefundamental goal of DDD: a design that reflects deep

understanding of the business problem at hand in a form that

of technical framework and architecture?

It is a common misperception, perhaps a natural one, that such

a priority on the domain demands less technical talent and skill.Would that this were true It would not be quite so difficult tobecome a competent domain designer Ironically, to render clearand useful domain concepts in software, to keep them from

being suffocated under technical clutter, requires particularlydeft use of technology My observation is that those with thegreatest mastery of technology and architectural principles

often know how to keep technology in its place and are amongthe most effective domain modelers

I do not refer to the knowledge of every quirk of complex tools,but to the mastery of the sort of knowledge laid out in MartinFowler's PoEAA, because nạve application of technology

paradoxically makes that technology more intrusive into theapplication

For many people this book will fill in gaps of how to implementexpressive object models in practice I picked up a number ofuseful ways of thinking through the application of technical

frameworks, and I especially firmed up my understanding ofsome particulars of doing DDD in a NET setting

In addition to technical architecture, Jimmy spends a great deal

of time on how to write tests TDD complements DDD in a

different way In the absence of a focus on refining an ever

more useful model, TDD is prone to fragmented applications,where a single-minded attack on one feature at a time leads to

an unextendable system A comprehensive test suite actuallyallows such a team to continue making progress longer thanwould be possible without it, but this is just the basest value ofTDD

At its best, the test suite is the laboratory for the domain modeland a technical expression of the ubiquitous language Tests of

it focused This book steps us through examples of developingsuch tests

Jimmy Nilsson has a rare combination of self-confidence andhumility, which I have observed to be characteristic of the bestdesigners We get a glimpse of how he got to his current

understanding as he tells us what he used to believe and whythat opinion changed, which helps to take the reader past thespecifics of the techniques to the underlying principles This

humility makes him open to a wide range of influences, whichgives us this fusion of ideas from different sources He has tried

a lot of things and has let his results and experience be his

guide His conclusions are not presented as revealed truth, but

as his best understanding so far with an implicit recognition that

we never have complete knowledge All this makes the advicemore useful to the reader And this attitude, in itself, illustrates

an important element of successful software development

leadership

Eric Evans

On the cover of this book is a picture of the Øresund Bridge thatconnects Sweden and Denmark It seems that all software

architecture books must have a bridge on the cover, but thereare some additional reasons the bridge is appropriate for thisbook

This bridge replaced a ferry that I took many times as a child Ienjoy very much driving over it even after dozens of times

On a personal note, my father was on the team that built thehighest parts of the bridge

But beyond these, the main reason is that this book is very

much about bridging gaps; bridging gaps between users anddevelopers; 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 [GoFDesign Patterns] Hey, how geeky can a preface be?

Focus of This Book

The main focus of the book is how a Domain Model could beconstructed to be clean, yet still be persistence-friendly It

shows what the persistence solution could look like for such aDomain Model and especially how to bridge that gap betweenthe 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

concrete examples are helpful regarding persistence, for

example Mine may be fairly basic, but it is a platform to startfrom This book not only explains how to use the patterns, butalso 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 haveproven to be general enough to use and reuse in context aftercontext

The focus isn't on the patterns themselves, but this book usespatterns in every chapter as a tool and language for discussingdifferent design aspects A nice side effect is that patterns-

ignorant readers will also gain some insight and interest intopatterns 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 NETcommunity that TDD (just as patterns) is considered a nichetechnique at best, or it might even be totally unknown Readerswill 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 waspretty sure I wouldn't write another, but the time came when Ithought I had something to say that I couldn't leave unsaid

My change of heart started when I read two recent books thatinspired 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

DDD] This book provided me with insights about how to thinkand act regarding development with a strong domain focus andwith 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 withstudents 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 calledValhalla, which I developed in collaboration with Christoffer

Skjoldborg (Christoffer did by far the most work.)

To summarize all this, I felt that a book that dealt more withapplication than theory was needed, but one that was based onsolid ground, such as the DDD and PoEAA books "Applying"feels close to my heart because I consider myself a developerabove anything else

platform boxes The book should serve NET people who want amore core-based approach than drag-till-you-drop (if I may usesome weak generalizations) Java people should get somethingout of the discussions and examples of how to combine DDDand O/R Mapping

I think the chosen language/platform is less and less important,

so it feels a little strange to talk about NET people and Javapeople Let's try to describe the target audience by using

another dimension Then I think that the book is for developers,team leaders, and architects

Part I: Background

In this part, we discuss architecture and processes in generalterms There is a lot of emphasis on Domain Models and DDD[Evans DDD] We also introduce patterns and TDD The

Chapter 2, "A Head Start on Patterns"

This chapter focuses on providing examples and discussionsabout patterns from different families, such as design

patterns, architectural patterns and domain patterns

Chapter 3, "TDD and Refactoring"

Chapter 1 talks quite a lot about TDD and refactoring, but inthis chapter there is more in-depth coverage with prettylong examples and also different flavors of TDD

Part II: Applying DDD

In this part, it's time to apply DDD We also prepare the DomainModel for the infrastructure, and focus quite a lot on rules

aspects

Chapter 4, "A New Default Architecture"

This chapter lists a set of requirements of an example

application, and a first-try model is created as a start forthe coming chapters A Domain Model-based architecture isused

Chapter 5, "Moving Further with Domain-Driven Design"

The requirements set up in the prior chapter are used inthis chapter as the basis for slowly, with TDD, starting tobuild the Domain Model in a DDD-ish style

Chapter 6, "Preparing for Infrastructure"

ahead and prepare the Domain Model for the infrastructureneeds In this chapter, there is a lot of discussion about

pros and cons of Persistence Ignorant Domain Models

Chapter 7, "Let the Rules Rule"

This chapter talks about business rules in the form of

validation and how a Domain Model-based solution can dealwith the need for such rules, connecting back to the

take a look at how those requirements are fulfilled by an

example tool

Chapter 8, "Infrastructure for Persistence"

When we have a fairly good Domain Model, it's time to thinkabout infrastructure, and the main type of infrastructure inthis book is infrastructure for persistence This chapter

discusses different properties of persistence solutions andhow to categorize a certain solution

Chapter 9, "Putting NHibernate into Action"

This chapter uses the categorizations of the prior chapterwith an example of a persistence solution, namely

NHibernate [NHibernate]

In this part, there is a focus on other design techniques to keep

an eye on and start using The other focus is on how you candeal with the presentation layer when it comes to bridging thatgap to the Domain Model, but also how to deal with developertesting of the UI This part is almost exclusively written by

guest authors

Chapter 10, "Design Techniques to Embrace"

After a short discussion about Bounded Context, this

chapter discusses design techniques to keep an eye on nowand for the future, such as Service Orientation, DependencyInjection/Inversion of Control, and Aspect Orientation

Chapter 11, "Focus on the UI"

This chapter focuses on how the UI can be connected to theDomain Model and how to increase testability for the userinterface when using a Domain Model, both for rich clientapplications and Web applications

Appendices

There are two appendices providing further examples of DomainModel styles and an overview-type patterns catalog

Why C# for the Examples?

In no way is this a book for teaching C# But I still need a

language (or possibly several, but I have chosen one) for theexamples, and that's where C# comes in

Regarding the version, most of the code examples work in bothC# 1.1 and 2.0, but there are some rare sections that are

focused on 2.0

Topics That Aren't Covered

There are loads of topics that aren't covered in the book, but Ithink there are two missing topics that spring to mind They aredistribution and advanced modeling

Distribution

It was in my early plans of the book to include thorough

coverage of the distribution aspects, but later on I came to theconclusion that the book would become too unfocused Still,there is some coverage here and there

Advanced Modeling

The title of the book might suggest that you find advanced andinteresting examples of modeling of certain problem areas

That's not exactly the case Instead, the application focus ismore about applying TDD and adding infrastructure to DDD

finally{}

As you can appreciate, a book project like this is hardly ever thework of only one person On the contrary, it's a joint effort Seethe list of people in the Acknowledgments section, and also

especially during production That said, any errors we didn'tcatch before the book went to print are mine and mine alone

I will post information of interest to readers of the book at

www.jnsk.se/adddp

Getting back to bridging gaps, the photo of the Øresund Bridgewas taken by my friend Magnus von Schenck on one of hissailing trips

Even though this book has not been as tough to write as thefirst one, there has been a fair amount of blood, sweat, andtears I hope the book might save you some of that Have funand good luck!

With the risk of forgetting some people that should get a

mention here (if so, you know who you are and a big thanks toyou, too), I say a huge thanks to the following:

My foreword authors: Martin Fowler and Eric Evans

My guest authors: Frans Bouma, Dan Byström, Udi Dahan, ErikDörnenburg, Mats Helander, Ingemar Lundberg, Philip Nelson,Claudio Perrone, Aleksandar Seovi , and Christoffer Skjoldborg

My reviewers who provided lots of valuable feedback: WilliamBulley, Mark Burhop, Dan Byström, Russ Condick, Andy Conrad,Christian Crowhurst, Mike Dörfler, Steve Eichert, Eric Evans,Martin Fowler, Paul Gielens, Chris Haddad, Kim Harding

Christensen, Mats Helander, Neeraj Gupta, Anders Hessellund,Roger Johansson, Roger Kratz, Trond-Eirik Kolloen, IngemarLundberg, Patrik Löwendahl, Marcus Mac Innes, Philip Nelson,Per-Ola Nilsson, Fredrik Normén, Johan Normén, Michael

O'Brien, Michael Platt, Sébastien Ros, Martin Rosén-Lidholm,Enrico Sabbadin, Aleksandar Seovi , Christoffer Skjoldborg,George Vish II, Gregory Young, and Christer Åkesson

Without you there would be no book, or at least a book ofinferior quality Thanks guys, I owe you!

In the "Background" part, we discuss architecture and processes in general terms.

There is a lot of emphasis on Domain Models and Domain-Driven Design (DDD) [Evans DDD] We also introduce patterns and Test-Driven Development (TDD).

The first part is about setting the scene Romeo and Juliet must have a scene.

Chapter 1 Values to Value

Chapter 2 A Head Start on Patterns

Chapter 3 TDD and Refactoring

the overall idea is to discuss values to value regarding

architecture and processes for development

On this journey, we will introduce and talk about many conceptsthat we will discuss in depth later on in the book

Start the camera Action!

In the past, I was very good at planning ahead I often addedfunctionality, structures, and mechanisms to my projects

proactively That part usually turned out pretty well, but I oftenforgot about the artifacts added on that never came to any

good use Of course, I added loads of them, too The cost waspretty large, both in development time and in increased

complexity

Over the last few years, we've been encouraged to use anotherapproach: "Do the simplest thing that could possibly work." To a

large extent, the idea comes from the Extreme Programming

(XP) movement [Beck XP] Another fairly similar way to put it is

"You Aren't Going to Need It" (YAGNI), which is a good way ofhelping you stay in line I guess "Keep It Simple Stupid" (KISS)could go here, too

Both approaches are kind of the two extremes (add all you canthink of up front versus do the simplest thing), but I think theyboth miss something in that they don't address the tradeoffsthey make Just about every question regarding "is this or thatbest" can be answered with "it depends." It's about tradeoffs Itend to prefer an approach that is somewhere in the middle,moving in one or the other direction depending upon the

situation The word "lagom" is a Swedish word meaning

something like "just right" or "not too much, not too little."

Lagom or "to balance" together with being context sensitive arethe overall values I'd like to value, as well as continuous

learning

Let's have a closer look at a couple of more specific areas ofvalues (architecture and process ingredients), starting with

some aimed at architecture to get us into the right mood