CODEWITHSUNDEEP
restdomain-driven-design
user1555190
user1555190

Reputation: 3239

language in microservice RESt API design

So im in the middle of breaking up a monolith, and i have decomposed it into services. However i came across something interesting.

We have a scenario where a customer is referred to as "customer", "client", "prospect"

And they all mean the same thing.

Now when designing the endpoints for the services... i can stick to each service having and using these different terms... but it doesnt feel right.

Should we align to using the same term, since they mean the same thing?

Upvotes: 1

Views: 60

Answers (3)

inf3rno
inf3rno

Reputation: 26147

It is right. In domain driven design you have bounded contexts where the same thing is described with different terms. The most famous example is cart product (catalog context), order item (invoice), package item (delivery context), etc. Or you can have user, customer, recipient, etc. in different bounded contexts. They can have the exact same id, they can even be in a single query database table if you want it so. You feel it not right, because it violates the DRY principle, but other principles can be stronger than DRY.

Upvotes: 0

Jocke
Jocke

Reputation: 424

It is likely that this is a case of different bounded contexts, where the same thing might be referred to using different terms, or the other way around, where the same word might have different meanings. It is important to understand and map these contexts, so that ambiguities can be minimized and interrelationships between these bounded contexts be made explicit. Breaking down a monolith is a typical case where these kinds of issues come to light, where multiple bounded contexts have been forced to live together and as such have gotten entangled - something that should be sorted out when breaking out separate services to ensure good decoupling. That being said, it might also just be that different terms have been used at random. Either way you should strive for a ubiquitous language; agreeing with domain experts around unambiguous and consistent terminology and then sticking to it everywhere; in code, documentation, communication, you name it.

Upvotes: 1

ArwynFr
ArwynFr

Reputation: 1722

One principles of DDD is ubiquitous language. You should ask your business experts to select one, which has less probability of being misunderstood by every stakeholder, and replace all others with that one.

Upvotes: 0

Related Questions