Domain driven design: Manager and service

I'm creating some business logic in the application but I'm not sure how o开发者_Go百科r where to encapsulate it, I've used the repository pattern for data access, I've seen some projects that use DDD that have some classes with the "Service" suffix and the "manager" suffix, what are each of this clases suppose to take care of in DDD?

Try to be as specific as possible with the name. As a rule of thumb I would avoid the name "Manager", as its meaning is quite vague.

Typical business logic actors/nouns would be Validators, Rules, Providers, Supervisors, Importers/Exporters, Serializers, Processors (process a transaction), and Repositories (the last of which you already have). If a single class is performing more than one of these functions, it should probably be broken down into subclasses.

You asked the question, "what do these classes take care of?" and indeed, that is the point. The name SomethingManager tells you nothing. OrderValidator, on the other hand, tells you pretty clearly what the class does, as does CustomerHistoryExporter. Services are kind of in the gray area; if the services is named after a passive action, like ShippingService, then it's pretty clear what the service deals with, but a better name might be something like ShipmentDispatcher. You get the idea, I hope.

Don't get too hung up on the nomenclature; in general, services provide something to classes so as to reduce coupling, and manager is more general still -- might be something a class that keeps track of other objects and/or state.

Far more important to a DDD approach is to actually model the domain. This is heavily dependent on your industry (or the industry that your app targets) and the type of application you're building. "Where to encapsulate?" is the basic driving force in this process, but it largely comes down to creating class-representations of real-world entities: employees, clients, vendors, invoices, transactions, quotes, contracts, etc.

Services and Managers may help glue these things together at runtime, and that nomenclature helps to distinguish these classes from things that encapsulate domain logic.

In a scenario where you have decided to use the Domain Model pattern(clearly if you want to do DDD), business logic such as validations, calculations and business rules definitely forms part of the domain model (your business objects and relations thereof).

A good general reference might also give you Martin Fowlers book 'Patterns of Enterprise Application Architecture'.