Thursday, May 11, 2017

Focus on verbs, not on names

In my experience, a good strategy to understand deeply a system or a product is:
  • Focus the research and conversations on identifying behaviors (actions, verbs, business flows, and events). 
  • For these behaviors, we should identify the dependencies, concurrency and parallelism requirements (what depends on what? what actions can happen at the same time? what actions don't depend on any other action? what are the sources/inputs for each action? etc). 

Understanding the concurrent behaviors, allow us to design the system using small pieces that encapsulate state and communicate using messages. A good match for OOP, Actors, Microservices, etc.
Is easy to see that this strategy try to identify the interactions that the users have with our system and the corresponding actions (verbs). It does not focus on the entities used by the system (names).
However, the most used analysis strategy try to identify the entities first, losing all the context about the behavior (messages, flows, rules, etc). This strategy derives, not necessarily, but typically, on anemic and poor models. This is a common approach for people who have misunderstood OOP/OOA.


I value the process of identifying the entities (names) of a system, but I value more identifying the behaviors (verbs) that define how is used our system and what actions provide to the user.

We should remember that the customer DON'T want software/systems. The software is only a liability, not an asset. The asset is the actions provided to the customer.

Additional notes:
  • This strategy can be used at different levels... It helps us to identify bounded contexts, domain events, microservices... And at the low level can also help us to see the concurrent behaviors of each application or service. This allows us to design more reactive and concurrent systems. 
  • Focusing on identifying names first, make very hard to fulfill concurrency, parallelism and scalability requirements. 
  • In the real world, things happen concurrently. 
  • Event storming seems to be a good exercise to identify the domain events, the dependencies, and the behaviors. 
  • Any strategy for the analysis should be used continuously. For me, development is always iterative, I don't see it any other way. 


Alfred J. Cuack said...

Maybe DDD didn't help much o some of us misunderstood it.

eferro said...

Mintxelas... yes both are important and needed, but I prefer to focus on verbs and thinking about the corresponding nouns as additional information, than to focus on nouns and not thinking too much about the actions.
For sure nouns are important but for me, less important.

In a phone system, we should focus on calling or having a phone call. For sure is important that we have customers in our network, and that we connect to another customer even from other networks, but the system should focus on the action "calling", and the entity customer or the entity customer location, is important but secondary... for example this information is important to "audit" the calls, to "invoice" the customer, to "route" the call... But the main focus on a phone system is to allow phone calls, not on manage customers.

The Idea is that focusing on verbs, the nouns appear... but when the focus is on nouns, not necessarily, but typically, we lost information.

I'm not sure I'm making myself clear.

eferro said...

Regarding the DDD, I know that the tactical patterns talk about entities, value objects, and so on... and I am not saying that these are not important, but The most significant message of the Domain-Driven Design strategy is talking about the domain knowledge, identifying the bounded contexts and understanding the business needs, and this are actions, in a hospital, the business is curing a patient, to diagnose, etc... the main business concepts are not "nurse", "doctor", "patient", these are concepts that play a role...

eferro said...

verbs without a noun have no value, but if you ask for a noun, they can answer that we have "invoices", we have "customers" and so on... and if you ask for actions they can answer with processes, flows, and events (including everything, verbs and nouns)... (e.g. When we deliver the product we invoice the customer sending by email the invoce).
So yes, you need everything, but you get a better answer if you ask for actions first (sure that the nouns come in the answer). :-)