Domain Driven Design

“As software developers, we fail in two ways: we build the thing wrong, or we build the wrong thing.”  – Steven Smith, 2014.

Domain Driven Design is an approach to build better software applications. Nillsson and Green (2014) describe it as a collaboration between domain experts and software developers. This is contrary to data driven design, which has no contact between designers and developers. Traditionally, senior developers would write the framework, then hand off the domain to be written by the less experienced developers (Friberg 2015). Domain Driven Design turns this concept on its head by making the domain the crucial component. The Domain Driven Design approach begins with opening communication between software developers and domain experts, this gives the developers a chance to fully explore what the client understands their needs are and enables the developers to begin thinking about code that would perfectly meets those needs. It is important to understand the context to be able to add it to the code, if it is important to the client, it should be in the code (Green & Nillsson 2014). At this stage the developers can begin to paint the overall picture of the subsystem. User stories are created with specific examples to present to the domain expert. It is important that software developers step outside of coding language and use ubiquitous language with conversations between the software developers and domain experts (Friberg 2015, Green & Nillsson 2014). This ubiquitous language is then used in all aspects including the code, design documents and conversations, thus preventing confusion and ensuring both teams have a clear understanding of the design and processes (Smith 2014). Once user stories are agreed upon, it is time to sketch them out. These sketches can be scenarios, storyboards, simple coded prototypes or UML. It is important to utilise the strong communication foundation and ensure the storyboard scenarios meet the client’s needs. Only then can writing the code begin. The initial stage of coding is used to test the system by using the scenarios as test cases (Green & Nillsson 2014). These scenarios are tested one by one adapting and adding classes and components as needed. It is an iterative process allowing the developers to improve and better understand the client’s requirements. The Domain Driven Design approach results in greater flexibility, better understanding of the problem by the customer, and better communication of the clients needs by the developer.

References
Friberg R, 21 September 2015, DotNetFringe Conf, online video, accessed 12 September 2016.
https://www.youtube.com/watch?v=0WO3H_MOjrI

Green R & Nillsson J, 18 September 2014, TechEd, online video, accessed 12 September 2016.
https://www.youtube.com/watch?v=FVGE00rUJow

Smith S, 28 September 2014, Domain-Driven Design with ASP.NET MVC, accessed 12 September 2016.
http://www.slideshare.net/ardalis/ddd-aspnet-mvc