,
5 tweets,
2 min read
Read on Twitter
Are you designing software with names like these?
Task<IGameGrain> GetCurrentGame();
Mono<Employee> getEmployeeById(String id);
Flux<Employee> getAllEmployees();
Really? Is that your final answer?
Task<IGameGrain> GetCurrentGame();
Mono<Employee> getEmployeeById(String id);
Flux<Employee> getAllEmployees();
Really? Is that your final answer?
Poor choices:
1. Technical component name in protocol.
2. Task doesn't describe the eventual completion of an async value.
3. Mono " " " " " " " ...
4. Flux " " " " " " " ...
5. The word Get/get/GeT/gEt/geT/etc.
1. Technical component name in protocol.
2. Task doesn't describe the eventual completion of an async value.
3. Mono " " " " " " " ...
4. Flux " " " " " " " ...
5. The word Get/get/GeT/gEt/geT/etc.
Many such names become glyphs. They only represent something that you intend, they don't describe what you intend. Your brain will ultimately filter this noise out of your way, because they have no meaning.
Names matter. Stop being a programmer *only*.
Names matter. Stop being a programmer *only*.
If you are still wondering what to do in place of poor naming, here are some ideas. These use the @vlingo_io platform toolkit for actor-based asynchronous operations and pipelines.
docs.vlingo.io/vlingo-common#…
docs.vlingo.io/vlingo-common#…
This demonstrates that fluency in your models is more than your Ubiquitous Language. The surrounding platform must not get in the way of your expressiveness and reasoning powers. Otherwise, you are halfway into contextual misalignment and you haven't even started yet.
