Evans - Domain-driven design: tackling complexity in the heart of software

This book belongs on the shelf of every thoughtful software developer.

Kent Beck

Eric Evans has written a fantastic book on how you can make the design of your software match your mental model of the problem domain you are addressing.

His book is very compatible with XP. It is not about drawing pictures of a domain; it is about how you think of it, the language you use to talk about it, and how you organize your software to reflect your improving understanding of it. Eric thinks that learning about your problem domain is as likely to happen at the end of your project as at the beginning, and so refactoring is a big part of his technique.

The book is a fun read. Eric has lots of interesting stories, and he has a way with words. I see this book as essential reading for software developersit is a future classic.

Ralph Johnson, author of Design Patterns

If you dont think you are getting value from your investment in object-oriented programming, this book will tell you what youve forgotten to do.

Ward Cunningham

What Eric has managed to capture is a part of the design process that experienced object designers have always used, but that we have been singularly unsuccessful as a group in conveying to the rest of the industry. Weve given away bits and pieces of this knowledge... but weve never organized and systematized the principles of building domain logic. This book is important.

Kyle Brown, author of Enterprise Java Programming with IBM WebSphere

Eric Evans convincingly argues for the importance of domain modeling as the central focus of development and provides a solid framework and set of techniques for accomplishing it. This is timeless wisdom, and will hold up long after the methodologies du jour have gone out of fashion.

Dave Collins, author of Designing Object-Oriented User Interfaces

Eric weaves real-world experience modelingand buildingbusiness applications into a practical, useful book. Written from the perspective of a trusted practitioner, Erics descriptions of ubiquitous language, the benefits of sharing models with users, object life-cycle management, logical and physical application structuring, and the process and results of deep refactoring are major contributions to our field.

Luke Hohmann, author of Beyond Software Architecture

Tackling Complexity in the Heart of Software

Eric Evans

Upper Saddle River, NJ Boston Indianapolis San Francisco
New York Toronto Montreal London Munich Paris Madrid
Capetown Sydney Tokyo Singapore Mexico City

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and Addison-Wesley was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals.

The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.

See page for photo credits.

The publisher offers discounts on this book when ordered in quantity for bulk purchases and special sales. For more information, please contact:

U.S. Corporate and Government Sales
(800) 382-3419

For sales outside of the U.S., please contact:

International Sales

Visit Addison-Wesley on the Web: www.awprofessional.com

Library of Congress Cataloging-in-Publication Data
Evans, Eric, 1962
Domain-driven design : tackling complexity in the heart of software / Eric
Evans.
p. cm.
Includes bibliographical references and index.
ISBN 0-321-12521-5
1. Computer softwareDevelopment. 2. Object-oriented programming
(Computer science) I. Title.
QA76.76.D47E82 2003
005.1dc21
2003050331

Copyright 2004 by Eric Evans

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. Printed in the United States of America. Published simultaneously in Canada.

For information on obtaining permission for use of material from this work, please submit a written request to:

Pearson Education, Inc.
Rights and Contracts Department
500 Boylston Street, Suite 900
Boston, MA 02116
Fax: (617) 671-3447

ISBN 0-321-12521-5
Text printed in the United States on recycled paper at Courier in Westford,
Massachusetts.
Twenty-First printing, July 2015

To Mom and Dad

There are many things that make software development complex. But the heart of this complexity is the essential intricacy of the problem domain itself. If youre trying to add automation to complicated human enterprise, then your software cannot dodge this complexityall it can do is control it.

The key to controlling complexity is a good domain model, a model that goes beyond a surface vision of a domain by introducing an underlying structure, which gives the software developers the leverage they need. A good domain model can be incredibly valuable, but its not something thats easy to make. Few people can do it well, and its very hard to teach.

Eric Evans is one of those few who can create domain models well. I discovered this by working with himone of those wonderful times when you find a client whos more skilled than you are. Our collaboration was short but enormous fun. Since then weve stayed in touch, and Ive watched this book gestate slowly.

Its been well worth the wait.

This book has evolved into one that satisfies a huge ambition: To describe and build a vocabulary about the very art of domain modeling. To provide a frame of reference through which we can explain this activity as well as teach this hard-to-learn skill. Its a book thats given me many new ideas as it has taken shape, and Id be astonished if even old hands at conceptual modeling dont get a raft of new ideas from reading this book.

Eric also cements many of the things that weve learned over the years. First, in domain modeling, you shouldnt separate the concepts from the implementation. An effective domain modeler can not only use a whiteboard with an accountant, but also write Java with a programmer. Partly this is true because you cannot build a that ties domain experts and technologists together.

Another lesson youll learn from this book is that domain models arent first modeled and then implemented. Like many people, Ive come to reject the phased thinking of design, then build. But the lesson of Erics experience is that the really powerful domain models evolve over time, and even the most experienced modelers find that they gain their best ideas after the initial releases of a system.

I think, and hope, that this will be an enormously influential book. One that will add structure and cohesion to a very slippery field while it teaches a lot of people how to use a valuable tool. Domain models can have big consequences in controlling software developmentin whatever language or environment they are implemented.