3 ms·

It is part of the application, and thus part of the domain. A class that is responsible for getting status updates from facebook is part of your model. The wa

It is part of the application, and thus part of the domain. A class that is responsible for getting status updates from facebook is part of your model. The way you say "updates your user model" makes it seem like you are thinking about the model as modelling the database. You keep saying this "has no business being in the model", but you haven't supported that in any way. Why doesn't it belong in the model?

karmajunkie 14y ago
[HN is weird. wouldn't let me post on this earlier, and I was moving it to your post now when you replied.] Its not a part of your application. You have to connect to facebook over a network to get to it. That data is very clearly NOT a part of your application. Now if a facebook profile is actually a part of your domain in some way, you're going to have a class specifically to manage that. Connecting to the network to update that still isn't a part of that class's responsibility. Look at it this way: if there were someone who knew everything about your problem area, would their knowledge of the behavior of the data include reaching out to facebook and pulling it in over a network connection? almost certainly not, unless your domain is that of a browser. If your domain is something like klout, for example, your domain is going to include concepts like profiles, connections, posts, etc. Its not going to include anything involving Net::HTTP.
- saurik 14y ago
  [For future reference, you often cannot reply to a post very soon after it is posted from the tree view, but if you click "link" you will be able to reply from the page that zooms in on just that one post.] As I describe in more detail in my other post, but will put more succinctly and from a different standpoint here: you are confusing the conversation by treating "model" vs. "domain" as if they were equivalent concerns (then to rely on arguments that things outside the domain must be outside the model), while the (possibly quite valuable) school of thought you are invoking puts the "domain" as only part of the model and defines other components that happily include your connections to external state.
  - karmajunkie 14y ago
    Fair enough—i've been using model in the same sense that Rails tends to, which is to say AR models. All the same, if we're going to use 'model' to refer to any number of classes dealing with application logic (regardless of whether its domain logic) then I return to my earlier argument that the Facebook connection example definitely lies outside the domain (and should also lie outside any AR models used) and that it should belong in a service class used by the application logic. I think we're talking in the same direction but terminology is getting in the way.

karmajunkie 14y ago

[HN is weird. wouldn't let me post on this earlier, and I was moving it to your post now when you replied.] Its not a part of your application. You have to connect to facebook over a network to get to it. That data is very clearly NOT a part of your application. Now if a facebook profile is actually a part of your domain in some way, you're going to have a class specifically to manage that. Connecting to the network to update that still isn't a part of that class's responsibility. Look at it this way: if there were someone who knew everything about your problem area, would their knowledge of the behavior of the data include reaching out to facebook and pulling it in over a network connection? almost certainly not, unless your domain is that of a browser. If your domain is something like klout, for example, your domain is going to include concepts like profiles, connections, posts, etc. Its not going to include anything involving Net::HTTP.

saurik 14y ago
[For future reference, you often cannot reply to a post very soon after it is posted from the tree view, but if you click "link" you will be able to reply from the page that zooms in on just that one post.] As I describe in more detail in my other post, but will put more succinctly and from a different standpoint here: you are confusing the conversation by treating "model" vs. "domain" as if they were equivalent concerns (then to rely on arguments that things outside the domain must be outside the model), while the (possibly quite valuable) school of thought you are invoking puts the "domain" as only part of the model and defines other components that happily include your connections to external state.
- karmajunkie 14y ago
  Fair enough—i've been using model in the same sense that Rails tends to, which is to say AR models. All the same, if we're going to use 'model' to refer to any number of classes dealing with application logic (regardless of whether its domain logic) then I return to my earlier argument that the Facebook connection example definitely lies outside the domain (and should also lie outside any AR models used) and that it should belong in a service class used by the application logic. I think we're talking in the same direction but terminology is getting in the way.