Domain-driven design

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Domain-driven design (DDD) is an approach to the design of software, based on the two premises [1] 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[2].

In the book Domain-Driven Design[2], a number of high-level concepts and practices are articulated, such as ubiquitous language meaning that the domain model should form a common language given by domain experts 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. In DDD, there are artifacts to express, create, and retrieve domain models:

  • 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 describes a characteristic of a thing. Value Objects have no conceptual identity. They are typically read-only objects and may be shared using the Flyweight design pattern.
  • Services: 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.
  • Repositories: methods for retrieving domain objects should delegate to a specialized Repository object such that alternative storage implementations may be easily interchanged.
  • Factories: methods for creating domain objects should delegate to a specialized Factory object such that alternative implementations may be easily interchanged.

Contents

[edit] Relationship to other ideas

Object-oriented analysis and design
Although in theory, the general idea of DDD need not be restricted to object-oriented approaches, in practice DDD seeks to exploit the powerful advantages that object-oriented techniques make possible.
Model-driven engineering (MDE)
Model-driven architecture (MDA)
While DDD is compatible with MDA, the intent of the two concepts is somewhat different. MDA is concerned more with the means of translating a model into code for different technology platforms than with the practice of defining better domain models.
POJOs and POCOs
POJOs and POCOs are technical implementation concepts, specific to the Java and .NET framework respectively . However, the emergence of the terms POJO and POCO, reflect a growing view that, within the context of either of those technical platforms, domain objects should be defined purely to implement the business behaviour of the corresponding domain concept, rather than be defined by the requirements of a more specific technology framework.
The naked objects pattern
This pattern is based on the premise that if you have a good enough domain model, the user interface can simply be a reflection of this domain model; and that if you require the user interface to be direct reflection of the domain model then this will force the design of a better domain model.[3]
Domain-specific programming language (DSL)
DDD does not specifically require the use of a DSL, though it could be used to help define a DSL and support methods like domain-specific multimodeling.
Aspect-oriented programming (AOP)
AOP makes it easy to factor out technical concerns (such as security, transaction management, logging) from a domain model, and as such makes it easier to design and implement domain models that focus purely on the business logic.

[edit] Software tools to support domain-driven design

Practicing DDD does not depend upon the use of any particular software tool or framework. Nonetheless, there is a growing number of open-source tools and frameworks that provide support to the specific patterns advocated in Evans' book and/or the general approach of DDD. Among these are:

  • OpenXava: Generates an AJAX application from JPA entities. Only it's needed to write the domain classes to obtain a ready to use application.
  • Roma Meta Framework: DDD centric framework. The innovative holistic approach lets the designer/developer to view anything as a POJO: GUI, I18N, Persistence, etc.
  • ECO (Domain Driven Design): Framework with database, class, code and state machine generation from UML diagrams by CapableObjects.
  • Naked Objects: implements the naked objects pattern; supports dependency injection; and provides re-usable implementations of the DDD concepts of Repository, Factory and Service.
  • FLOW3: A PHP based application framework centered on DDD principles. Fosters clean Domain Models and supports the concept of Repository, Entity and Value Object. Also provides Dependency Injection and an AOP framework.
  • Strandz: A DD framework that provides implementation independence from both the UI layer and domain layer of the application. The programmer constructs a wire model of the application using special classes.
  • Castle Windsor/MicroKernel: an Inversion of Control/Dependency Injection container for the Microsoft.NET Framework to provide Services, Repositories and Factories to consumers.
  • Sculptor: a code-generation framework that uses DDD terminology.
  • Domdrides: A useful library for implementing DOMain-DRIven DESign in Java.
  • TrueView for .NET: An easy-to-use framework that supports DDD and the naked objects pattern. Useful for teams starting out with DDD.
  • Sculpture - Model Your Life: Is a .NET open source Model-Driven Development code generation framework ideal for creating and managing .NET Enterprise Applications, comes with a host of ready-made Molds (The word “Molds” comes from Molding) like (DAAB, NHibernate, LINQ, CSLA, WCF, ASMX, Windows forms, WPF, Silverlight, ASP.NET, & ASP.NET MVC).
  • Habanero.NET (Habanero) is an Open Source Enterprise Application framework for creating Enterprise applications using the principles of Domain-driven design and implemented in .NET.

[edit] References

  1. ^ Definition on domaindrivendesign.org
  2. ^ a b Evans, E., Domain-Driven Design - Tackling Complexity in the Heart of Software, 2004, Addison-Wesley
  3. ^ Haywood, D., Domain-Driven Design using Naked Objects, 2009, Pragmatic Programmers

[edit] External links

Retrieved from "http://en.wikipedia.org/wiki/Domain-driven_design"
Personal tools
Languages