3 ms·
The name is an abstraction. Naming it "cache" is not specific enough. The uses and functionality of services change over time and then you have to rename them.
by honkycat 4y ago
The name is an abstraction. Naming it "cache" is not specific enough.
The uses and functionality of services change over time and then you have to rename them.
We have a service called "Search" that does... much much more than search. If we had named it "Harry" we could put a README in the project root and avoid confusion.
In fact, looking around my current work's stack... we have a LOT of "boring" service names that no longer describe what the service actually does.
- preseinger 4y agoIf a search service does more than search, this is a problem to be solved, not a property to be accommodated in a naming scheme. One of the core purposes of a service oriented architecture is to define and enforce bounded contexts. Purpose-driven names reinforce that goal.
- stevebmark 4y agoDDD is a poison to the mind and business growth. Keep the domain at the user configuration level where possible, not locked in to service design. Build domain agnostic, functionality based services. You shouldn't need to channel engineering to iterate on your business model. In the context of naming services it's even worse, trying to name services after significant domains in your business is an even stronger lock-in of temporary business concepts to service design. It's a poisonous coupling.
- preseinger 4y agoNah. The "service architecture" is literally dictated by the business. DDD is a way to model that reality.