Domain objects/services and the Business Logic Layer
What are domain objects and domain services in software architecture? I am not familiar with them or how they differ from the business logic layer?
Answer
Different people use these terms in somewhat different ways, but here's my take:
1) "Business" and "domain" are roughly synonyms. "Domain" is a bit more general in that it doesn't make the assumption that you're writing a business application. So if we were writing a scientific app or a game, we might prefer to refer to the relevant part of the code as "domain" code rather than "business" code. So in the remainder of this explanation I'll use "domain" since it's more general.
2) "Domain logic" comprehends both "domain objects" and "domain services". For various reasons (technical and otherwise) many architectures employ a design where the domain logic is divided into objects for storing data ("domain objects") and objects that manipulate those ("domain services"). Martin Fowler and others have pointed out that that's not very OO since a big part of the OO concept is to put functionality together with data, and that's right, but it is what it is. Domain objects are the data and domain services are the do-stuff-with-the-data part.
3) In domain-driven design, the idea is to get back to true OO design, and so the various service methods make their way back to the domain objects so that you have objects in the OO sense rather than what are sometimes called "anemic" objects. In a DDD the domain objects themselves are more robust and so they form the domain logic. In reality there may still be some domain services too, but this is typically smaller in a DDD than in a more traditional domain objects vs. services model.