Return to Answer

Create behavior code that doesn't know how to find anything, doesn't transform the format of anything, and doesn't decide where to put anything. It does one thing, on the one format it expects, that gets handed to it, and puts the result wherever its told to put it.

Create behavior code that doesn't know how to find anything, doesn't transform the format of anything, and doesn't decide where to put anything. It does one thing, on the one format it expects, that gets handed to it, and puts the result wherever its told to put it. ^seriously

But, in either case don't you have views? Or presenters? Or whatever you want to call them? Somewhere something has to know how you want that name displayed. I see no reason to let that detail leak into your data model. Formatting the name "manually" seems to be the thing to do. But code that knows how to format it and code that knows how to get it don't have to live together. Separate these concerns. Even if you make the CA use case responsible for the transformation doesn’t mean it can’t make some behavior object do it.

But, in either case don't you have views? Or presenters? Or whatever you want to call them? Somewhere something has to know how you want that name displayed. I see no reason to let that detail leak into your data model. Formatting the name "manually" seems to be the thing to do. But code that knows how to format it and code that knows how to get it don't have to live together. Separate these concerns. Even if you make the CA use case responsible for the transformation doesn’t mean it can’t make some behavior objects do it.

But, in either case don't you have views? Or presenters? Or whatever you want to call them? Somewhere something has to know how you want that name displayed. I see no reason to let that detail leak into your data model. Formatting the name "manually" seems to be the thing to do. But code that knows how to format it and code that knows how to get it don't have to live together. Separate these concerns. Call them whatever you like. Just use names that make their jobs clear or they'll fill up with clutter.

But, in either case don't you have views? Or presenters? Or whatever you want to call them? Somewhere something has to know how you want that name displayed. I see no reason to let that detail leak into your data model. Formatting the name "manually" seems to be the thing to do. But code that knows how to format it and code that knows how to get it don't have to live together. Separate these concerns. Even if you make the CA use case responsible for the transformation doesn’t mean it can’t make some behavior object do it.

Call them whatever you like. Just use names that make their jobs clear or they'll fill up with clutter.