Domain Driven Testing - What is it Exactly?
![Image](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDuz3rUiltWzovhWgt57g9zfaT2VIyzdMxXy8EtTLdh1ffKxRWigfavjOc5SedsucfpGSh017ATT2y5mtFeZFFVGRJ5Iv61nzyOr4JN2-qTgJ3qie2f7txm6NGT0m0fBU3zuoQW02Uf9I/w304-h400/TheBlueBook.jpg)
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 test