4 ms·

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

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.
      - 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.
- deleted 14y ago
  [deleted]
  - papsosouid 14y ago
    All that I am getting is that you seem convinced that the model is purely data. It isn't. Behaviours are part of the model. The behaviour of "getting info from some remote data source" is absolutely part of the model.
    - karmajunkie 14y ago
      Actually, if you're playing with DCI, your data classes should be thin data containers. But that's neither here nor there. Even in a more typical Rails application, domain behaviors are supposed to be on the model. The responsibility for going over a network is almost never going to be a domain behavior. Just because you use the data in some way doesn't make it a domain behavior. Getting data from a remote data source is definitely not a part of the domain, and the fact that Rails has many developers convinced that's the way its supposed to be illustrates just how far down the rabbit hole the Rails world has fallen.
- saurik 14y ago
  From this same argument, a connection to a database by definition is outside the scope of your domain because it is also outside of your application, and that you should instead have something like a Command or Job that accesses the database storage backend and updates it, thereby placing the database outside of the scope of the model. The goal of the "model" in MVC is to build an in-application model of outside-application (possibly "real world") state, whether it be a tree of browser bookmarks in folders or a tree of files in filesystem folders or a tree of reports in a command hierarchy; as your application needs to be able to understand these things, it needs to model them. In an ideal world, your model presents a reasonably abstract rendition of the thing that you are modeling (so that you will be able to reuse views and controllers for anything that is sort of tree-like), however you may also be modeling something very particular to your application, in which case you will have a rather convoluted one-off model. Now, to be clear, I'm not disagreeing with your suggestion of how to structure the logic of your application: having a bunch of data that is manipulated by connections to external systems can make a lot of sense; however, when "domain oriented design" is talked about, AFAIK the entire purpose is to decide how to internally structure your model, taking it as a given that, from an MVC perspective, that is where all of these behaviors and state are supposed to be kept. http://blog.fedecarg.com/2009/03/11/domain-driven-design-and-mvc-architectures/ http://blog.fedecarg.com/2009/03/11/domain-driven-design-and... > Domain-driven design separates the model layer “M” of MVC into an application, domain and infrastructure layer. The infrastructure layer is used to retrieve and store data. The domain layer is where the business knowledge or expertise is. The application layer is responsible for coordinating the infrastructure and domain layers to make a useful application.

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.
    - 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.
deleted 14y ago
[deleted]
- papsosouid 14y ago
  All that I am getting is that you seem convinced that the model is purely data. It isn't. Behaviours are part of the model. The behaviour of "getting info from some remote data source" is absolutely part of the model.
  - karmajunkie 14y ago
    Actually, if you're playing with DCI, your data classes should be thin data containers. But that's neither here nor there. Even in a more typical Rails application, domain behaviors are supposed to be on the model. The responsibility for going over a network is almost never going to be a domain behavior. Just because you use the data in some way doesn't make it a domain behavior. Getting data from a remote data source is definitely not a part of the domain, and the fact that Rails has many developers convinced that's the way its supposed to be illustrates just how far down the rabbit hole the Rails world has fallen.
saurik 14y ago
From this same argument, a connection to a database by definition is outside the scope of your domain because it is also outside of your application, and that you should instead have something like a Command or Job that accesses the database storage backend and updates it, thereby placing the database outside of the scope of the model. The goal of the "model" in MVC is to build an in-application model of outside-application (possibly "real world") state, whether it be a tree of browser bookmarks in folders or a tree of files in filesystem folders or a tree of reports in a command hierarchy; as your application needs to be able to understand these things, it needs to model them. In an ideal world, your model presents a reasonably abstract rendition of the thing that you are modeling (so that you will be able to reuse views and controllers for anything that is sort of tree-like), however you may also be modeling something very particular to your application, in which case you will have a rather convoluted one-off model. Now, to be clear, I'm not disagreeing with your suggestion of how to structure the logic of your application: having a bunch of data that is manipulated by connections to external systems can make a lot of sense; however, when "domain oriented design" is talked about, AFAIK the entire purpose is to decide how to internally structure your model, taking it as a given that, from an MVC perspective, that is where all of these behaviors and state are supposed to be kept. http://blog.fedecarg.com/2009/03/11/domain-driven-design-and-mvc-architectures/ http://blog.fedecarg.com/2009/03/11/domain-driven-design-and... > Domain-driven design separates the model layer “M” of MVC into an application, domain and infrastructure layer. The infrastructure layer is used to retrieve and store data. The domain layer is where the business knowledge or expertise is. The application layer is responsible for coordinating the infrastructure and domain layers to make a useful application.