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?
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.
The Business Logic Layer is also called the Domain Layer. This is the layer/tier that handles all the business logic.
Domain Objects and Domain Services are classes that you use to build your Domain Layer.
We need to understand the responsibilities of the application layer and the domain (business) layer to be able to grasp the difference. The domain layer is representing the business objects, mainly entities from the business, possibly abstracted to some degree, and domain services. The domain layer only changes when the business changes or the context of the domain changes within the business. The application layer "lives" on top of the domain layer and is often (preferably) separated from the domain layer, like with an asp.net MVC Web application where the controller part is the application layer and the HTML part is the presentation layer. The application layer changes to accommodate the purpose of that specific application (or service, API, app etc.)
Let me offer this example of an enterprise application scenario i have worked with, to explain why a domain tier and a business tier both contain business logic but are different.
Suppose i have a COTS product that is a pure Case Management engine, say a OMG CMMN implementation. A whole bunch of business logic in a business tier which works with a bunch of entities from the data tier.
Now continue to suppose that I have two customers that are systems integrators, one is building a Legal case management sytem and one that wants Health care case management. both are case management, but have thier own domain terms, objects, procedures, industry architectures, etc.
Each will add thier own domain tier, so that they can work in the terms and concepts of the respective business domain.
So yes its contains business logic, but a domain tier is a way of encapsulating a generic reusable business with a specific business.
The 'simpler' the application the more similar the domain model and the data model are, and the business logic and domain logic. But when you increase 'utility' of a component diverge, eventually the concerns are separated.
来源：https://stackoverflow.com/questions/5589141/domain-objects-services-and-the-business-logic-layer