Floyd Marinescu - Domain-Driven Design Quickly

Contents

Free Online Version.

Support this work, buy the print copy:

http://infoq.com/books/domain-driven-design-quickly

2006 C4Media Inc.

All rights reserved.

C4Media, Publisher of InfoQ.com Enterprise Software Development Community

Part of the InfoQ Enterprise Software Development series of books.

For information or ordering of this or other InfoQ books, please contact books@c4media.com.

No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronical, mechanical, photocopying, recording, scanning or otherwise except as permitted under Sections 107 or 108 of the 1976 United States Copy-right Act, without either the prior written permission of the Publisher.

Designations used by companies to distinguish their products are often claimed as trademarks. In all instances where C4MEdia Inc. is aware of a claim, the product names appear in initial Capital or ALL CAPITAL LETTERS.

Readers, however, should contact the appropriate companies for more complete information regarding trademarks and registration.

Some of the diagrams used in this book were reproduced with permission, under Creative Commons License, courtesy of: Eric Evans, DOMAIN-DRIVEN DESIGN, Addison-Wesley, Eric Evans, 2004.

Cover page image republished under Creative Commons License, courtesy of: Eric Evans, DOMAIN-DRIVEN DESIGN, Addison-Wesley, Eric Evans, 2004.

Production Credits:

DDD Summary by: Abel Avram

Managing Editor: Floyd Marinescu

Cover art: Gene Steffanson

Composition: Laura Brown and Melissa Tessier

Special thanks to Eric Evans.

Preface: Why DDD Quickly?

I first heard about Domain Driven Design and met Eric Evans at a small gathering of architects at a mountain summit organized by Bruce Eckel in the summer of 2005. The summit was attended by a number of people I respect, including Martin Fowler, Rod Johnson, Cameron Purdy, Randy Stafford, and Gregor Hohpe.

The group seemed quite impressed with the vision of Domain Driven Design, and was eager to learn more about it. I also got the feeling that everyone wished that these concepts were more mainstream. When I noticed how Eric used the domain model to discuss solutions to some of the various technical challenges the group discussed, and how much emphasis he placed on the business domain instead of technology-specific hype, I knew right away that this vision is one that the community sorely needed.

We, in the enterprise development community, especially the web development community, have been tainted by years of hype that took us away from proper object oriented software development. In the Java community, good domain modeling was lost in the hype of EJB and the container/component models of 1999-2004. Luckily, shifts in technology and the collective experiences of the software development community are moving us back towards traditional object oriented paradigms. However, the community is lacking a clear vision for how to apply object orientation on an enterprise scale, which is why I think DDD is important.

Unfortunately, outside of a small group of the most senior architects, I perceived that very few people were aware of DDD, which is why InfoQ commissioned the writing of this book.

It is my hope that by publishing a short, quickly-readable summary and introduction to the fundamentals of DDD and making it freely downloadable on InfoQ with an inexpensive pocket-sized print version, this vision can become mainstream.

This book does not introduce any new concepts; it attempts to concisely summarize the essence of what DDD is, drawing mostly Eric Evans original book on the subject, as well other sources since published such as Jimmy Nilssons Applying DDD and various DDD discussion forums. The book will give you a crash course on the fundamentals of DDD, but it is no substitute for the numerous examples and case studies provided in Erics book or the hands-on examples provided in Jimmys book. I highly encourage you to read both of these excellent works. In the meantime, if you agree that the community needs DDD to be part of our group consciousness, please let people know about this book and Erics work.

Floyd Marinescu

Co-founder & Chief Editor of InfoQ.com

Introduction

Software is an instrument created to help us deal with the complexities of our modern life. Software is just the means to an end, and usually that end is something very practical and real. For example, we use software for air traffic control, and this is directly related to the world surrounding us. We want to fly from one place to another, and we do that using sophisticated machineries, so we create software to coordinate the flight of thousands of airplanes which happen to be in the air at any time.

Software has to be practical and useful; otherwise we would not invest so much time and resources into its creation. That makes it extremely connected to a certain aspect of our lives. A useful package of software cannot be decoupled from that sphere of reality, the domain it is supposed to help us manage. On the contrary, the software is deeply entangled with it.

Software design is an art, and like any art it cannot be taught and learned as a precise science, by means of theorems and formulas. We can discover principles and techniques useful to be applied throughout the process of software creation, but we probably wont ever be able to provide an exact path to follow from the real world need to the code module meant to serve that need. Like a picture or a building, a software product will include the personal touch of those who designed and developed it, something of the charisma and flair (or the lack of it) of those who contributed to its inception and growth.

There are different ways to approach software design. For the last 20 years, the software industry has known and used several methods to create its products, each with its advantages and shortcomings. The purpose of this book is to focus on a design method which has emerged and evolved over the last two decades, but has crystallized more clearly during the last few years: domain-driven design. Eric Evans has made a great contribution to this subject matter by writing down in one book much of the accumulated knowledge about domain-driven design. For a more detailed presentation of this topic, we recommend reading his book Domain-Driven Design: Tackling Complexity in the Heart of Software, published by Addison-Wesley, ISBN: 0-321-12521-5.

Many valuable insights can also be learned by following the Domain Driven Design discussion group at:

http://groups.yahoo.com/group/domaindrivendesign

This book is only an introduction to the topic, intended to quickly give you a fundamental, but not a detailed understanding of Domain Driven Design. We just want to whet your appetite for good software design with the principles and guidelines used in the world of domain-driven design.

What Is Domain-Driven Design

Software development is most often applied to automating processes that exist in the real world, or providing solutions to real business problems; The business processes being automated or real world problems that the software is the domain of the software. We must understand from the beginning that software is originated from and deeply related to this domain.

Software is made up of code. We might be tempted to spend too much time with the code, and view the software as simply objects and methods.

Consider car manufacturing as a metaphor. The workers involved in auto manufacturing may specialize in producing parts of the car, but in doing so they often have a limited view of the entire car manufacturing process. They start viewing the car as a huge collection of parts which need to fit together, but a car is much more than that. A good car starts with a vision. It starts with carefully written specifications. And it continues with design. Lots and lots of design. Months, maybe years of time spent on design, changing and refining it until it reaches perfection, until it reflects the original vision. The processing design is not all on paper. Much of it includes doing models of the car, and testing them under certain conditions to see if they work. The design is modified based on the testing results. The car is sent to production eventually, and the parts are created and assembled together.