Menu
Every entity in the system, representing the human-world object which the system is expected to interact with is a business object. The human-world logic in the system around manipulating business objects is a business logic. This is opposed to the objects and logic being part of the implementation details.
The business logic layer is the business components that provide OAGIS services to return data or start business processes. The presentation layer uses these OAGIS services to display data, or to invoke a business process. The business logic provides data required by the presentation layer.
All invariant to use-cases logic (business entities, business workflow components, e.g. Domain model, Domain services) goes to the Domain layer (Domain logic). This layer is responsible for concepts of the business domain and business rules.
A domain object is an entity in the domain layer of your application, eg. an Address class. "Model" means the same thing - an entity in the "Domain Model". A POCO (plain old CLR object) is an object that has no behaviour (methods) defined, and only contains data (properties).
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.)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With