6 fix grammar
source | link

For me, I go by the Eric Evans definition of service which is something like this:

Generally, in a well designed system, most classes (in the Domain Model) have quite clear responsibility or function in that they deal with a specific entity or set of entities in the model.

i.e.

  • Account, Account Factory, Account Repository, etc
  • Customer, Customer Factory, Customer Repository, etc

When you have functionality that does not belong with any particular entity it can be difficult to find a correct place for it to sit. I.e something that encapsulates a process that involves both an Account AND a Customer .

So, that's where a service comes in. It's where you put code that is in the Domain Model but does not naturally belong to one entity/component or another.

I think of a helper as a kind of strategy class. To me its a place to put code that needs to be re-used by various classes but might not quite sit well as abstract methods inside the hierarchy of the classes who use it. Personally I find the term helper a bit vague and don't really have them in my model. Although they exist in libraries that I use.

For me, I go by the Eric Evans definition of service which is something like this:

Generally, in well designed system, most classes (in the Domain Model) have quite clear responsibility or function in that they deal with a specific entity or set of entities in the model.

i.e.

  • Account, Account Factory, Account Repository, etc
  • Customer, Customer Factory, Customer Repository, etc

When you have functionality that does not belong with any particular entity it can be difficult to find a correct place for it to sit. I.e something that encapsulates a process that involves both an Account AND a Customer .

So, that's where a service comes in. It's where you put code that is in the Domain Model but does not naturally belong to one entity/component or another.

I think of a helper as a kind of strategy class. To me its a place to put code that needs to be re-used by various classes but might not quite sit well as abstract methods inside the hierarchy of the classes who use it. Personally I find the term helper a bit vague and don't really have them in my model. Although they exist in libraries that I use.

For me, I go by the Eric Evans definition of service which is something like this:

Generally, in a well designed system, most classes (in the Domain Model) have quite clear responsibility or function in that they deal with a specific entity or set of entities in the model.

i.e.

  • Account, Account Factory, Account Repository, etc
  • Customer, Customer Factory, Customer Repository, etc

When you have functionality that does not belong with any particular entity it can be difficult to find a correct place for it to sit. I.e something that encapsulates a process that involves both an Account AND a Customer .

So, that's where a service comes in. It's where you put code that is in the Domain Model but does not naturally belong to one entity/component or another.

I think of a helper as a kind of strategy class. To me its a place to put code that needs to be re-used by various classes but might not quite sit well as abstract methods inside the hierarchy of the classes who use it. Personally I find the term helper a bit vague and don't really have them in my model. Although they exist in libraries that I use.

5 added 27 characters in body
source | link

For me, I go by the Eric Evans definition of service which is something like this:

Generally, in well designed system, most classes (in the Domain Model) have quite clear responsibility or function in that they deal with a specific entity or set of entities in the model.

i.e.

  • Account, Account Factory, Account Repository, etc
  • Customer, Customer Factory, Customer Repository, etc

When you have functionality that does not belong with any particular entity it can be difficult to find a correct place for it to sit. I.e something that encapsulates a process that involves both an Account AND a Customer .

So, that's where a service comes in. It's where you put code that is in the Domain Model but does not naturally belong to one entity/component or another.

I think of a helper as a kind of strategy class. To me its a place to put code that needs to be re-used by various classes but might not quite sit well as abstract methods inside the hierarchy of the classes who use it. Personally I find the term helper a bit vague and don't really have them in my model. Although they exist in libraries that I use.

For me, I go by the Eric Evans definition of service which is something like this:

Generally, in well designed system, most classes (in the Domain Model) have quite clear responsibility or function in that they deal with a specific entity or set of entities in the model.

i.e.

  • Account, Account Factory, Account Repository, etc
  • Customer, Customer Factory, Customer Repository, etc

When you have functionality that does not belong with any particular entity it can be difficult to find a correct place for it to sit. I.e something that encapsulates a process that involves both an Account AND a Customer .

So, that's where a service comes in. It's where you put code that does not naturally belong to one entity/component or another.

I think of a helper as a kind of strategy class. To me its a place to put code that needs to be re-used by various classes but might not quite sit well as abstract methods inside the hierarchy of the classes who use it. Personally I find the term helper a bit vague and don't really have them in my model. Although they exist in libraries that I use.

For me, I go by the Eric Evans definition of service which is something like this:

Generally, in well designed system, most classes (in the Domain Model) have quite clear responsibility or function in that they deal with a specific entity or set of entities in the model.

i.e.

  • Account, Account Factory, Account Repository, etc
  • Customer, Customer Factory, Customer Repository, etc

When you have functionality that does not belong with any particular entity it can be difficult to find a correct place for it to sit. I.e something that encapsulates a process that involves both an Account AND a Customer .

So, that's where a service comes in. It's where you put code that is in the Domain Model but does not naturally belong to one entity/component or another.

I think of a helper as a kind of strategy class. To me its a place to put code that needs to be re-used by various classes but might not quite sit well as abstract methods inside the hierarchy of the classes who use it. Personally I find the term helper a bit vague and don't really have them in my model. Although they exist in libraries that I use.

4 added 22 characters in body
source | link

For me, I go by the Eric Evans definition of service which is something like this:

Generally, in well designed system, most classes (in the Domain Model) have quite clear responsibility or function in that they deal with a specific entity or set of entities in the model.

i.e.

  • Account, Account Factory, Account Repository, etc
  • Customer, Customer Factory, Customer Repository, etc

When you have functionality that does not belong with any particular entity it can be difficult to find a correct place for it to sit. I.e something that encapsulates a process that involves both an Account AND a Customer .

So, that's where a service comes in. It's where you put code that does not naturally belong to one entity/component or another.

I think of a helper as a kind of strategy class. To me its a place to put code that needs to be re-used by various classes but might not quite sit well as abstract methods inside the hierarchy of the classes who use it. Personally I find the term helper a bit vague and don't really have them in my model. Although they exist in libraries that I use.

For me, I go by the Eric Evans definition of service which is something like this:

Generally, in well designed system, most classes have quite clear responsibility or function in that they deal with a specific entity or set of entities in the model.

i.e.

  • Account, Account Factory, Account Repository, etc
  • Customer, Customer Factory, Customer Repository, etc

When you have functionality that does not belong with any particular entity it can be difficult to find a correct place for it to sit. I.e something that encapsulates a process that involves both an Account AND a Customer .

So, that's where a service comes in. It's where you put code that does not naturally belong to one entity/component or another.

I think of a helper as a kind of strategy class. To me its a place to put code that needs to be re-used by various classes but might not quite sit well as abstract methods inside the hierarchy of the classes who use it. Personally I find the term helper a bit vague and don't really have them in my model. Although they exist in libraries that I use.

For me, I go by the Eric Evans definition of service which is something like this:

Generally, in well designed system, most classes (in the Domain Model) have quite clear responsibility or function in that they deal with a specific entity or set of entities in the model.

i.e.

  • Account, Account Factory, Account Repository, etc
  • Customer, Customer Factory, Customer Repository, etc

When you have functionality that does not belong with any particular entity it can be difficult to find a correct place for it to sit. I.e something that encapsulates a process that involves both an Account AND a Customer .

So, that's where a service comes in. It's where you put code that does not naturally belong to one entity/component or another.

I think of a helper as a kind of strategy class. To me its a place to put code that needs to be re-used by various classes but might not quite sit well as abstract methods inside the hierarchy of the classes who use it. Personally I find the term helper a bit vague and don't really have them in my model. Although they exist in libraries that I use.

3 added 1 character in body
source | link
2 added 88 characters in body
source | link
1
source | link