rafanoronha.speaking()

When users interact with software, you bet they are focused in resolving simple and well defined tasks.

Let’s stay with two actions our users would like to perform, when dealing with a Sales System:

A) Change a Product’s Description.
B) Change a Product’s Category.

Changing the description of a product isn’t that big deal, and you should let the user do it with no more than data-entry level validations.
On the other side, changing the category of a product can bring some business side effects, for instance, if the business trusted in that information for dealing with some kind of pricing discount.

We have two completely different business actions here, and dealing at the same time with them and even another ones may not be the most coherent solution.

If you are approaching the Domain Model pattern, probably that kind of rule evaluation belongs to your business entities.
So maybe you do have a Product object implementing a weird isValid() method.
And every time an action is performed upon a Product, a lot of business rules are handled.
Even when the user only wanted to change a description.
To me, that really sounds silly.

So, what would be the alternative?

Complex business problems can appear from totally different scenarios.
Resolving when and how to handle these problems require the knowledge of what kind of action is being performed.

From the implementation perspective, you are going to ensure rules based on what is going on with your domain objects.
The Product object would have methods like changeDescription() and changeCategory().
The first one would be very straight-forward, while the second one would evaluate some business rules, which could result in the operation’s disapproval.

In this post I showed an alternative to a problematic implementation pattern.
On top of the same subject there are also more material for discussion.

Translation of user intent to the software’s core is something you definitely should care about.
That’s why it’s called ubiquitous language.

A bit of time ago I wrote about an issue surrounding the concept of Domain Driven Design.

Now I would like to give you one more tiny tip, on the matter of bringing business concepts to the code level of a software project.

Today a colleague and I were working on the domain model of my current project.
And he asked me if I was ok with calling a Repository interface something like ProductRepository.

I told him I don’t think it is a good idea to bring technical terms to the domain model of our software.
Do you think it is ok to use the name ProductEntity instead of Product?
So why are you naming repositories with a pattern suffix?

If you want to spend more time thinking in the business behind the piece of technology you are building, it’s a great first step to take technical terms away from your ubiquitous language.

I would like to share some thinking on Domain Driven Design.

The amazing value provided by Domain Driven Design is the focus on the business side of the Software.

This same focus brings a constraint to your software development process: IN-DEPTH Business Knowledge becomes a MUST HAVE.

I just want to make sure you will remember this constraint when planning to apply DDD.

If you have any sort of problem on the matter of handling this constraint, take my advice: Stay with the CRUD based option.

Domain Driven Design can absolutely improve what you are going to deliver to your customer.
But don’t expect all you have to do is having stuff that you call “Aggregate Root”, “Domain Model”, or “Repository”.