DDD — a superficial view

When I first started to study about architecture patterns, I quickly learned about TDD and BDD, but DDD was highly vague. I studied the concept, and was postponing the learning of the practical application. What I didn`t know was that I was working with DDD for the last months, without knowing.

Last year I started to help a team as a freelancer developer. They presented me a robust architecture with many layers such as "domain", "repository", etc, and it was my first practical contact with TDD. That architecture called my attention because it was so nice, clear and understandable to work with. I had to build my second project from scratch (for the same company), and decided to adopt the same architecture. What I didn`t know was that I built a project from scratch using DDD!

Domain Driven Design, a.k.a. DDD, is more difficult to understand in concept than in practice.

It is an approach to software development that places the primary focus on the core domain and domain logic. It bases the design on a model of the domain, it is trying to make your software a model of some real-world system or process.

You are supposed to work closely with a domain expert. Because of this, on DDD, you (developer) and the domain expert sould have a Ubiquitous Language (UL), which is basically a conceptual description of the system. These concepts will form the basis of your object-oriented design.

There are some concepts that you should consider when working with DDD:

• Repository: pattern for persistence;
• Service: pattern for creating objects/operations that manipulate the main domain objects but does not conceptually belong to any object.

To consciously start working with DDD, I got a very simple example that you can probably find the solution at Google (but I had to get my hands dirty). The DDD project is available at my GitHub account.

I started to build the solution with the DOMAIN project, that contains the classes of my domain: Categories and Products. After that, it was created a interface to the Repository and the Repository itself. For the Repository I used EntityFramework, and I didn`t implement all the methods because the intention was only to demonstrate the approach.

I will go deep on this architecture approach later, but, what you need to know by now is that, summarizing, in object-oriented design, the developer and the domain expert build together the domain (and you, developer, understand as classes), and from this you build the entire project.

See you on the next post :)

References:

• Stackoverflow — Can Someone Explain DDD in Plain English Please?
• Wikipedia — Domain Driven Design