TrafficLight Experiment. Advantage of DDD approach to the problem Traffic Light, say goodbye to public properties It is a long time I did not post about simple Traffic Light experiment. I’ve ended with a super simple Domain with no Getters and no Setters, but there is still something I really do not like about that [...]

Continue reading about Traffic light vNext

I’ve more to say about the Traffic Light example I explained in a previous post, if you look at that post, you can notice that the Domain is composed by properties that have only getter and not setters. This needs is explained in this post, where I explain why you should protect the status of [...]

Continue reading about Traffic light, say goodbye to public properties

I’m reading the exceptional Object Thinking book, full of interesting considerations about thinking with an Object Oriented mind. One of the main concept of the book is that quite often we are using objects in a procedural way so we are still in the realm of procedural programming even using inheritance, constructor, etc etc. As [...]

Continue reading about Is my Domain Model really anemic?

Fluent interfaces are great for a various amount of situations because they permit to create a simple DSL using only the base capabilities of your language of choice. I like very much Fluent Interfaces especially to create Factories to avoid messing with several constructors when your classes are complex to create. The model Suppose you [...]

Continue reading about Fluent interface for factory to create hierarchy of objects

If you read my last post, I explain how I solved a really stupid problem of managing a Traffic Light using OOP principles and the concept of Domain Events, now I want to emphasize some of the advantages you have using this approach. One benefit is in unit testing, suppose you want to test that [...]

Continue reading about Advantage of DDD approach to problem