3 ms·

I don't understand the distinction of "not domain logic". If your application requirements are "when user does X, update facebook" then that is clearly part of

I don't understand the distinction of "not domain logic". If your application requirements are "when user does X, update facebook" then that is clearly part of the domain and should absolutely be in the models.

karmajunkie 14y ago
Oh, i disagree with that completely. A user having a status is domain logic. Pulling that status from an external dependency is decidedly not.
- endersshadow 14y ago
  How is it not? What draws the line between domain logic and non-domain logic? It would seem to me that, by definition, anything your application does would fall into that application's domain, right? What other domain would it be in? Where would you put a request to a third party for supplemental data, if not in the models?
  - karmajunkie 14y ago
    If it were part of your domain, it'd be part of your application. Connection to facebook by definition is outside the scope of your domain. You can take a couple of different strategies to it, but in general the best way to handle that is to introduce a class whose responsibility is to connect to facebook and return a status (generally speaking, a Service) and something like a Command or Job that accesses the FacebookService and updates your user model. Part of the problem with speaking about domains here (aside from being nonspecific about something that is by its very nature quite specific) is that Rails has an extraordinariliy half-assed approach to domain oriented design (I don't want to use 'DDD' here just to avoid buzzwords). Developers have been told for years to just push it into the model because all the work belongs there, but that's BS. a LOT of the work has no business being there.
    - papsosouid 14y ago
      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.
- strictfp 14y ago
  I like to think of the problem like this: Imagine building another interface to your app. Take a CLI as an example. Should the 'facebook update' feature be activated if you use your app through the CLI? If the answer is yes, it belongs to the model. If no, it does not.

karmajunkie 14y ago

Oh, i disagree with that completely. A user having a status is domain logic. Pulling that status from an external dependency is decidedly not.

endersshadow 14y ago
How is it not? What draws the line between domain logic and non-domain logic? It would seem to me that, by definition, anything your application does would fall into that application's domain, right? What other domain would it be in? Where would you put a request to a third party for supplemental data, if not in the models?
- karmajunkie 14y ago
  If it were part of your domain, it'd be part of your application. Connection to facebook by definition is outside the scope of your domain. You can take a couple of different strategies to it, but in general the best way to handle that is to introduce a class whose responsibility is to connect to facebook and return a status (generally speaking, a Service) and something like a Command or Job that accesses the FacebookService and updates your user model. Part of the problem with speaking about domains here (aside from being nonspecific about something that is by its very nature quite specific) is that Rails has an extraordinariliy half-assed approach to domain oriented design (I don't want to use 'DDD' here just to avoid buzzwords). Developers have been told for years to just push it into the model because all the work belongs there, but that's BS. a LOT of the work has no business being there.
  - papsosouid 14y ago
    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.
strictfp 14y ago
I like to think of the problem like this: Imagine building another interface to your app. Take a CLI as an example. Should the 'facebook update' feature be activated if you use your app through the CLI? If the answer is yes, it belongs to the model. If no, it does not.