DDD - Domain Driven Design


(from Wikipedia)
Domain-driven design (DDD) is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts.1 The premise of domain-driven design is the following:

* Placing the project's primary focus on the core domain and domain logic
* Basing complex designs on a model
* Initiating a creative collaboration between technical and domain experts to iteratively cut ever closer to the conceptual heart of the problem.

Domain-driven design is not a technology or a methodology. DDD provides a structure of practices and terminology for making design decisions that focus and accelerate software projects dealing with complicated domains.

Core Definitions

(from Wikipedia)
* Domain: A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software.
* Model: A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.
* Ubiquitous Language: A language structured around the domain model and used by all team members to connect all the activities of the team with the software.
* Context: The setting in which a word or statement appears that determines its meaning.

Somethings that You find in DDD Designs

  • Domain: That's where you place your ValueObjects and _Entities
  • Repository: That's where you save your data
  • Services: That's where you write whatever "do stuff" in your architecture

You see in Abstract, but maybe not in DDD Designs

Domain Driven Design is very "friendly" to any implementations that follows the basis of its concept, like said by Eric Evans in his "Tackling Domain Complexity".
We took advantage of that and included a few things that really make sense in daily programming.
  • Providers: Whatever IS infra-structural but doesn't suite the name Repository goes into a Provider within Abstract
  • Enumerations: We needed so badly to have a cross-cutting list of enumerations that we pushed that into the Domain layer.

Further Reading

  • (from Amazon): "The software development community widely acknowledges that domain modeling is central to software design. Through domain models, software developers are able to express rich functionality and translate it into a software implementation that truly serves the needs of its users. But despite its obvious importance, there are few practical resources that explain how to incorporate effective domain modeling into the software development process." (see http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215)

  • (from Manning): "A successful ASP.NET application needs to accomplish its functional goals, provide a comfortable user experience, and be easy to deploy, maintain, and extend. ASP.NET MVC is a development framework designed around these principles. It provides the structure you need to follow the Model-View-Controller (MVC) design pattern, in which an application is divided into three distinct parts: Model(...), View(...), Controller(...)" (see http://www.manning.com/palermo3/)

Last edited Sep 10, 2011 at 12:46 AM by hudsonmendes, version 2


No comments yet.