Allan,

A question about your example: What would you do if you requirement is that it can be a TimeInterval that mixes the Business Hours and Overtime Period - in you example you consider it a kind overtime, but let’s say that we want to divide it in some hours for Business and some overtime ? How would you build your classes ?

I’m no expert in this domain but if that was a requirement I’d say that there is a third Kind of TimeInterval that models that. But the best answer would be: ask your domain expert.

Rodrigo,

Most people praise this as a flexible solution, as rules can be dynamically added and removed and the model object will remain the same.

For me this sentence clearly states that the system is not built using Domain-Driven Design. If it was then the “model objects” would have to model the business domain and that includes those rules.

That said, DDD is not a requirement and there are cases where it’s not even the best solution. If the developers know that they are not following DDD and have a good reason in doing so then I can see no problem.

Cheers all

Most systems I’ve seen have some kind of validation engine built-in. An anemic domain object is built and submitted for verification. As this engine checks the internals of other objects, isn’t that an encapsulation violation? Most people praise this as a flexible solution, as rules can be dynamically added and removed and the model object will remain the same. On the other hand, domain objects can be created in inconsistent states, leading to obscure bugs.

What do you think about that? What is the best approach for validation in your opinion?

Value objects can be smaller or bigger and, if we stick to DDD, the same applies to entities, services etc… I just think it is better to categorise them after their essential responsibility in the design instead of after their accidental tininess.

I totally agree that a wise design strategy is to make explicit all the relevant domain concepts, and only them. This leads to a simple and expressive design, that facilitates both software maintenance and collaboration with stakeholders.

I think the key issue here is the discernment of what is relevant and what is not in the context of each project and domain. As usual, this is critical for healthily applying any design principle.

Cheers,
Rafael

A question about your example: What would you do if you requirement is that it can be a TimeInterval that mixes the Business Hours and Overtime Period - in you example you consider it a kind overtime, but let’s say that we want to divide it in some hours for Business and some overtime ? How would you build your classes ?

Thanks,
Alan

Rafael Peixoto,

Tiny Types are different from Value Object. Although something “TinyType’d” is very likely to be a Value Object that is not a requirement. And Value Objects don’t have to be “tiny” in any sense.

Batman,

Your message got approved only because I recognised the IP address, please use your real name from now on

The thing about operators is probably true but I tend to not use language features that will introduce noise to readers coming from other languages.

Rafael Noronha,

I’ve done Design By Contract and even implemented my own libraries for that. I like the concept but I am still not convinced that it makes sense as part of the object model for languages like C# or Java.

Cheers all

Something that also seems to bring expressiveness is the concept of code contracts, e.g. Spec#.

Have you tried it?

In you Contract example, you could reduce the noise you mention by adding implicit operators (for casting to/from int) to your Years class.

Nice post. I like the way you show the need for careful design in order to avoid creating irrelevant types or breaking apart single (or tightly related) domain concepts.

By the way, I prefer using the term “value object” over “tiny type”, because the latter represents to me a pure (and less relevant) focus on syntax. For the sake of “minimal integrity”, I would also explicitly add the requirement that “from” be less than “to”, since they are just integers.

Thanks for another “well designed” post with clear thinking and simple examples about relevant design issues.