Domain-Driven Design

The most complicated aspect of large software projects is not the implementation, it is the real world domain that the software serves. Over the last decade or two, a Domain-Driven Design philosophy has developed as an undercurrent in the object community.

What Is Domain-Driven Design?

Domain-driven design (DDD) is an approach to the design of software, based on the two premises that complex domain designs should be based on a model, and that, for most software projects, the primary focus should be on the domain and domain logic (as opposed to being the particular technology used to implement the system). The term was coined by Eric Evans in his book of the same title.

Domain-driven design is not a technology or a methodology. It is a vision and approach for dealing with highly complex domains that is based on making the domain itself the main focus of the project, and maintaining a software model that reflects a deep understanding of the domain. It is a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains. To accomplish that goal, teams need an extensive set of design practices, techniques and principles.

In DDD a number of specific software design patterns are useful, such as:

Entities (a.k.a. Reference Objects): An object in the domain model that is not defined by its attributes, but rather by a thread of continuity and identity.

Value Objects: An object that has no conceptual identity. These objects describe a characteristic of a thing.

Repository: methods for retrieving domain objects should delegate to a specialised 'repository' object such that alternative implementations may be easily interchanged.

Factory: methods for creating domain objects should delegate to a specialised 'factory' object such that alternative implementations may be easily interchanged.

Service: When an operation does not conceptually belong to any object. Following the natural contours of the problem, you can implement these operations in services. The Service concept is called "Pure Fabrication" in GRASP.

Some of the very good books for reference are :

Domain-Driven Design: Tackling Complexity in the Heart of Software

In the book Domain-Driven Design a number of high-level concepts and practices are articulated, such as ubiquitous language meaning that the domain model should form a common language for describing system requirements, that works equally well for the business users or sponsors and for the software developers. The book is very focused at describing the Domain layer which is one of the common layers in an object-oriented system with a multilayered architecture.

With this book in hand, object-oriented developers, system analysts, and designers will have the guidance they need to organize and focus their work, create rich and useful domain models, and leverage those models into quality, long-lasting software implementations.

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

From the Back Cover
“[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.

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 databases–even with other platforms, such as J2EE.