IT:AD:DDD:When To Use
## When to Use DDD ## * DDD is useful for applications that have a Domain to speak of – not just data to update and report on. * Probably 95% of all software applications fall into the “not so good for using DDD” categories. Most are fundamentally updating and reporting applications that are data centric. * The question is then … will the app grow to have a Domain worth refactoring into a Domain Layer?
`As the core of the software is the domain model, which is a direct projection of this shared language, it allows the team to quickly find gaps in the software by analyzing the language around it. The creation of a common language is not merely an exercise in accepting information from the domain experts and applying it. Quite often, communication problems within development teams are due not only to misunderstanding the language of the domain, but also due to the fact that the domain's language is itself ambiguous. The Domain Driven Design process holds the goal not only of implementing the language being used, but also improving and refining the language of the domain. This in turn benefits the software being built, since the model is a direct projection of the domain language.`
>`In order to help maintain the model as a pure and helpful language construct, you must typically implement a great deal of isolation and encapsulation within the domain model. Consequently, a system based on Domain Driven Design can come at a relatively high cost. While Domain Driven Design provides many technical benefits, such as maintainability, **it should be applied only to complex domains** where the model and the linguistic processes provide clear benefits in the communication of complex information, and in the formulation of a common understanding of the domain.`
Src:[http://msdn.microsoft.com/en-us/library/ee658117.aspx#DomainModelStyle]
`If the application to be developed is relatively simple, you do not foresee changes in
i
nfrastructure technology during the life of the application and, above all else, the business rules automated in the application will change very little, then your solution probably shouldn't follow [DDDD]. Instead … consider a RAD (Rapid Application Development) development technology.
Rapid implementation technologies can be very effective in building simple
applications where the de-coupling between components and layers is not particularly relevant, and the emphasis is on productivity and time to market. Typically, these kinds of apps are Data Driven Applications, rather than Domain Driven Designs.`
Src: DDDD Book
Alternatives
Don't throw out the baby with the bathwater.