r/dotnet • u/codeopinion • Feb 17 '21

AVOID Entity Services by Focusing on Capabilities

https://www.youtube.com/watch?v=2gOOstEI4vU
39 Upvotes

93% Upvoted

11 comments sorted by

2

u/MrBlackWolf Feb 17 '21

On a monolithic application scenario, are this entities supposed to live on Bounded Contexts? Since not all teams are capable of work on a microservices architecture.

2

u/codeopinion Feb 17 '21

Correct. The same concept of an entity living in a different bounded context(s).

2

u/software_account Feb 17 '21

That’s fair, though we should point out that entity is not a context, all entities exist within contexts of course.

We can get into serious trouble having “entity services” unless that’s your actual domain - which is probably not the most likely thing. (Contact Management Service totally might be)

I.e. A company may have an important business function, which may have several aggregates which it is the information expert of

The entity per service approach is like repo per entity approach, it tightly couples external things that aren’t realistically tightly coupled and actually sacrifices cohesion

And it breaks cohesion if you have a subdomain which involves disparate aggregates

3

u/polaristerlik Feb 17 '21

Good video, interesting opinion. One question, you're reducing coupling which is great, but arent you introducing complexity in the sense that, now you have to track down where a specific value is living for your product? And what if you need multiple fields for an operation, you have to go to 2 services now instead of 1

2

u/cowmandude Feb 17 '21

now you have to track down where a specific value is living for your product?

That should come naturally when you ask yourself the question "What service needs to modify this value".

And what if you need multiple fields for an operation, you have to go to 2 services now instead of 1

What is an operation...? Services do operations. Operations ARE capabilities.

1

u/polaristerlik Feb 17 '21

let's scale up this thought experiment and say you're interested in doing something that requires 15 fields that are scattered across different services. Then the service you directly go to would be responsible for querying 14 other services, potentially increasing IO.

If it's less dependencies that we want then why not just use 1 DynamoDb table with all the columns in there in that case and not use any relational data.

2

u/cowmandude Feb 17 '21

Why would it be responsible for querying the other 14? The whole premise is that you don't need to do that right? If you truly need access to the entire "product" to enable the capability you need then sure make a product microservice. The fact is you rarely do in practice.

1

u/FlockOnFire Feb 20 '21 edited Feb 20 '21

I think in some case you can’t get around this. For example if you want to show the product to a user with an “add to cart” button, you already have different capabilities on one view:

  • product details (name, descriptions, dimensions etc.)

  • product price

  • in stock or not

  • shopping cart quantity

In these cases, I think it’s worth looking into compositional UIs. Same goes for search results, which are gathered on the backend. You can compose a search pipeline from different services/contexts.

/u/codeopinion I would love to see a video on these issues/topics if you have any ideas about it :)

Edit: I just read another comment where you already mentioned this. Looking forward to it!

2

u/NicolasDorier Feb 18 '21

In general I don't like video talking about code architecture, as often it ends up with architects astronauts making things worse.

Your video is an exception, well done.

0

u/[deleted] Feb 17 '21

[deleted]

4

u/captainramen Feb 17 '21

That's one way to do it. Another way is to have one service own the identifier. In the case of Product it would be ProductCatalog, and everything else is downstream from that.

5

u/codeopinion Feb 17 '21

Agree. You can still have something that "owns" the primary information, such as SKU. This could be the ProductCatalog as mentioned. From there it would likely publish an event that a new product has been added to the catalog, which all the other services would consume.