I am afraid that I am having some similar misconceptions as you’ve had. Your post helped me put a finger on them. Only, this sounds great for applications which are geared towards the business user (=client application).

But what about specs for parts of frameworks? those are still geared towards users – but technical ones?

Example… UnitOfWorkGateway:

Context:
When_UnitOfWorkGateway_is_used_to_start_an_non_nested_Unit_repetedly_2_times

Specs:
- Then_the_first_Unit_should_be_created
- And_Gateway_IsUnitStarted_for_first_Unit_should_be_true
- And_second_Unit_should_be_created
- And_first _Unit_and_second_Unit_should_be_the_equal

How do you see these being expressed in the context of your post (which is I think on the correct track)?

Thanks,
Vladan

It’s not that setters are completely bad, just that they often don’t capture the “why”. Why did the value change, what was the business motivation behind that behavior. That’s often missing when the responsibility for maintaining correct Entity state is spread throughout the application.

Saying that the spec language is business-centric still betrays a technology-centric bias.

This language is as business-centric as the code is. Everything in a solution is business-centric – even the lambda expressions.

The point I’ve been making for a year or so is to “describe the experience, not the implementation”.

Another way to say this is that specifications are written in user goal language.

To say something is “business-centric” is to speak from a programmer’s biases and perspective with a lack of consciousness of the bias and perspective.

I can also definitely see BDD helping us see where a responsibility and in this case it makes sense to place the responsibility on Order. I’d go a step further and say that the default for domain related behavior should be that its in a method in the domain (unless its workflow/process logic that sometimes needs to sit outside the domain). If you go with this mindset then you’re really thinking what Entity/Value Object (or as a fallback Service) should this behavior go on, which I think can be very useful.

Still doesn’t turn me against setters though, I can see the sense in an almost complete ban on setters but even if you do that people without a good design mindset will just find another way of writing procedural code. I guess my thinking is still that good developers will make good use of setters in the domain and will know when to use a method.