Return to Answer

What is the difference between Use Cases and Core Services?

The name.

Sure there are a few different ideas here but there are far more names.

In the Microsoft's example, there are no Use Case classes

Really? Lets take a look:

• BasketService.cs
• OrderService.cs
• UriComposer.cs

eShopOnWeb - Services

Using a shopping basket seems fairly use casey to me. As does placing orders. Uri composing seems a little iffy but I wouldn't kick you out of a design review over it.

Understand, the objects themselves aren't use cases. They are objects that are beholden to the use case. Which is an entire story of a user using the application, in a particular case. Not an object. I've talked about this before. Uncle Bob has never said these objects are what use cases are. It's simply one (of many) names he sometimes uses for this layer.

Calling them "core services" doesn't really change what they are for. It changes who it seems like you're emulating as you put together the design. It makes me think the designer is following Jeffrey Palermo's Onion Architecture. To his credit, Uncle Bob outright admits he was following him too.

These superficial differences are why I call these, as well as hexagonal architecture, the buzzword architectures. The different names for the same ideas seem to be designed to drive you to particular blogs and books.

That isn't to say the ideas are bad. Just that there's a layer of hype to peel back to get to them. Once you do that, it can be nice to get the different perspectives. but it can cause a fair bit of confusion on the way there.

Of all the names to use for this stuff service is fairly neutral. It just means something that gets used. So don't assume just because the names don't end in UC that the same idea isn't alive in here.

What is the difference between Use Cases and Core Services?

In this context: the name.

Sure there are a few different ideas here but there are far more names.

In the Microsoft's example, there are no Use Case classes

Really? Lets take a look:

• BasketService.cs
• OrderService.cs
• UriComposer.cs

eShopOnWeb - Services

Using a shopping basket seems fairly use casey to me. As does placing orders. Uri composing seems a little iffy but I wouldn't kick you out of a design review over it.

Understand, the objects themselves aren't use cases. They are objects that are beholden to the use case. Which is an entire story of a user using the application, in a particular case. Not an object. I've talked about this before. Uncle Bob has never said these objects are what use cases are. It's simply one (of many) names he sometimes uses for this layer.

Calling them "core services" doesn't really change what they are for. It changes who it seems like you're emulating as you put together the design. It makes me think the designer is following Jeffrey Palermo's Onion Architecture. To his credit, Uncle Bob outright admits he was following him too.

These superficial differences are why I call these, as well as hexagonal architecture, the buzzword architectures. The different names for the same ideas seem to be designed to drive you to particular blogs and books.

That isn't to say the ideas are bad. Just that there's a layer of hype to peel back to get to them. Once you do that, it can be nice to get the different perspectives. but it can cause a fair bit of confusion on the way there.

Of all the names to use for this stuff service is fairly neutral. It just means something that gets used. So don't assume just because the names don't end in UC that the same idea isn't alive in here.

What is the difference between Use Cases and Core Services?

The name.

Sure there are a few different ideas here but there are far more names.

In the Microsoft's example, there are no Use Case classes

Really? Lets take a look:

• BasketService.cs
• OrderService.cs
• UriComposer.cs

eShopOnWeb - Services

Using a shopping basket seems fairly use casey to me. As does placing orders. Uri composing seems a little iffy but I wouldn't kick you out of a design review over it.

Understand the objects themselves aren't use cases. They are objects that are beholden to the use case (which is an entire story, not an object). I've talked about this before. Uncle Bob has never said these objects are what use cases are. It's simply one (of many) names he sometimes uses for this layer.

Calling them "core services" doesn't really change what they are for. It changes who it seems like you're emulating as you put together the design. It makes me think the designer is following Jeffrey Palermo's Onion Architecture. To his credit, Uncle Bob outright admits he was following him too.

These superficial differences are why I call these, as well as hexagonal architecture, the buzzword architectures. The different names for the same ideas seem to be designed to drive you to particular blogs and books.

That isn't to say the ideas are bad. Just that there's a layer of hype to peel back to get to them. Once you do that, it can be nice to get the different perspectives. but it can cause a fair bit of confusion on the way there.

Of all the names to use for this stuff service is fairly neutral. It just means something that gets used. So don't assume just because the names don't end in UC that the same idea isn't alive in here.

What is the difference between Use Cases and Core Services?

The name.

Sure there are a few different ideas here but there are far more names.

In the Microsoft's example, there are no Use Case classes

Really? Lets take a look:

• BasketService.cs
• OrderService.cs
• UriComposer.cs

eShopOnWeb - Services

Using a shopping basket seems fairly use casey to me. As does placing orders. Uri composing seems a little iffy but I wouldn't kick you out of a design review over it.

Understand, the objects themselves aren't use cases. They are objects that are beholden to the use case. Which is an entire story of a user using the application, in a particular case. Not an object. I've talked about this before. Uncle Bob has never said these objects are what use cases are. It's simply one (of many) names he sometimes uses for this layer.

Calling them "core services" doesn't really change what they are for. It changes who it seems like you're emulating as you put together the design. It makes me think the designer is following Jeffrey Palermo's Onion Architecture. To his credit, Uncle Bob outright admits he was following him too.

These superficial differences are why I call these, as well as hexagonal architecture, the buzzword architectures. The different names for the same ideas seem to be designed to drive you to particular blogs and books.

That isn't to say the ideas are bad. Just that there's a layer of hype to peel back to get to them. Once you do that, it can be nice to get the different perspectives. but it can cause a fair bit of confusion on the way there.

Of all the names to use for this stuff service is fairly neutral. It just means something that gets used. So don't assume just because the names don't end in UC that the same idea isn't alive in here.

What is the difference between Use Cases and Core Services?

The name.

Sure there are a few different ideas here but there are far more names.

In the Microsoft's example, there are no Use Case classes

Really? Lets take a look:

• BasketService.cs
• OrderService.cs
• UriComposer.cs

eShopOnWeb - Services

Using a shopping basket seems fairly use casey to me. As does placing orders. Uri composing seems a little iffy but I wouldn't kick you out of a design review over it.

Understand the objects themselves aren't use cases. They are objects that are beholden to the use case (which is an entire story, not an object). I've talked about this before. Uncle Bob has never said these objects are what use cases are. It's simply one (of many) names he sometimes uses for this layer.

Calling them "core services" doesn't really change what they are for. It changes who it seems like you're emulating as you put together the design. It makes me think the designer is following Jeffrey Palermo's Onion Architecture. To his credit Uncle Bob outright admits he was following him too.

These superficial differences are why I call these, as well as hexagonal architecture, the buzzword architectures. The different names for the same ideas seem to be designed to drive you to particular blogs and books.

That isn't to say the ideas are bad. Just that there's a layer of hype to peel back to get to them. Once you do that, it can be nice to get the different perspectives. but it can cause a fair bit of confusion on the way there.

Of all the names to use for this stuff service is fairly neutral. It just means something that gets used. So don't assume just because the names don't end in UC that the same idea isn't alive in here.

What is the difference between Use Cases and Core Services?

The name.

Sure there are a few different ideas here but there are far more names.

In the Microsoft's example, there are no Use Case classes

Really? Lets take a look:

• BasketService.cs
• OrderService.cs
• UriComposer.cs

eShopOnWeb - Services

Using a shopping basket seems fairly use casey to me. As does placing orders. Uri composing seems a little iffy but I wouldn't kick you out of a design review over it.

Understand the objects themselves aren't use cases. They are objects that are beholden to the use case (which is an entire story, not an object). I've talked about this before. Uncle Bob has never said these objects are what use cases are. It's simply one (of many) names he sometimes uses for this layer.

Calling them "core services" doesn't really change what they are for. It changes who it seems like you're emulating as you put together the design. It makes me think the designer is following Jeffrey Palermo's Onion Architecture. To his credit, Uncle Bob outright admits he was following him too.

These superficial differences are why I call these, as well as hexagonal architecture, the buzzword architectures. The different names for the same ideas seem to be designed to drive you to particular blogs and books.

That isn't to say the ideas are bad. Just that there's a layer of hype to peel back to get to them. Once you do that, it can be nice to get the different perspectives. but it can cause a fair bit of confusion on the way there.

Of all the names to use for this stuff service is fairly neutral. It just means something that gets used. So don't assume just because the names don't end in UC that the same idea isn't alive in here.