Domain Driven Testing - What is it Exactly?

Domain-Driven Design is not a new concept - it has been around since 2003 when Eric Evans published the "Blue Book". However, I did notice that there is not much material on the topic of testing within a DDD environment. This may be due to the fact that DDD is not some trendy hot fad, and from what I have noticed, there aren't that many companies using it. Using DDD for smaller projects, and projects where the business/domain logic is not overly complex is overkill - as DDD is meant to simplify a demanding project, on a small project applying DDD would have the opposite effect - it will just add more abstraction, which is not needed in this instance making a simple project a lot more complicated. Combined with the previously listed reasons, DDD shops usually use the TDD approach, so there is a lot of testing involved (especially automated testing) but it's done by the developers and not dedicated testers - and we all know that testers can talk on and on about testing, as that is our main focus.

All this lead me to do more research on this topic, as was working with DDD, as a new tester on the project, this relatively unexplored area appealed to me greatly. Domain-Driven Design is a very interesting approach to software design as it tackles some of the biggest pain points in software development, by making sure we have a clear and understandable requirement and by making the technical and the domain experts work closely together. So, let me share what I have observed and learned thus far!

The Benefits of Ubiquitous Language

Ubiquitous Language is a language-based around domain model and it is used by all the team members when discussing the domain. The purpose of the ubiquitous language is to make sure that everyone is on the same page - if everyone involved in the development of new software is using the same agreed-upon naming conventions it helps us avoid misconceptions, unclear requirements, and misunderstandings. By agreeing on the terminology which will be used we avoid a lot of back-and-forths and also restrict different interpretations of the domain logic - so we avoid situations where the domain experts want one thing to build, but the developers understand it in a different manner - saving us time in the long run by reducing the amount of re-work to a minimum. What does this mean in terms of testing? Many of us have probably faced situations where let's say the user story (or other form or requirement) uses one term and a different term is used in the application - the story might be referring to "accounts" but the applications ended up with the terms "companies" for the same thing, they are supposed to be synonymous in this situations, but this can create confusion and uncertainty and the Ubiquitous Language servers to prevent things like this from happening. Another benefit of using the Ubiquitous Language is that it can serve as a foundation for developing a DSL (Domain Specific Language). A DSL is a language built on top of a general-purpose language (such as C#, Java, etc.) and it has a narrow focus particular to its domain, the benefit of a DSL in testing is that it can be used like a low-code scripting language by the less-technical members of the team, as the technical details are abstracted away and the what's on the surface uses terminology that is already known to the domain experts. In summary, communication is essential for DDT to be successful. 

Understanding the Bounded Context of your Application

For complex systems segregating different segments of the domain helps us understand it better, it helps with design and maintenance as well. Bounded Context is a way of separating parts of your app into logical units, this is especially applicable when using a microservices architecture. Let us assume that you have a large app with many different functionalities, and you have to test the whole app. It's logical to assume that you would split the tests into different logical groups or modules and that is where understanding of bounded context can help. Works really well for exploratory testing sessions, where you can narrow down your focus, per session and dedicate your attention to exploring one functionality at a time.

Summary

• Based on the established ubiquitous language you can build your own DSL (domain-specific language), for example, to use in test automation to make it more accessible to less technical users, and also make it more focused on your product.
• Communication is of paramount importance for DDD testing since Domain-Driven Design puts a large emphasis on this as well - by having domain experts work closely with the technical experts to establish a common language - the ubiquitous language, which serves as a shared language and it's helpful in establishing clear requirement
• As DDD puts a large emphasis on clean code, using smart software architecture and TDD practices, the applications built using it are usually more stable and more testable.

This is a post I've started writing quite some time ago, and finally returned to finish it - there might be another one on the same topic soon. Thanks for taking the time to read the post, I hope it was useful to you!