Domain objects/services and the Business Logic Layer

Question

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?

Panteutonism

Answer 1

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.

Realm

@Willie Wheeler what should go into a domain object and what into domain services? I'm new to mvc. – Straggle

Reread #2 and #3 above. Anemic business objects are simpler to implement but arguably less in the OO-spirit. – Realm

@WillieWheeler Hey man, I am new to java and I am trying to learn how to construct beans/java domain objects properly. Let's sya I have a dragon and it can have multiple classes(roles). (e.g, a dragon can be a tracker, at the same time it can be a striker.). I plan to display the dragon classes in my home page, when you click a class, it will show you the list of dragons under that class but for some reason I find it really hard to come up of a structure on how to do this right – Offensive

@Carnal A usable answer won't fit in a comment. I suggest creating an actual question for this at programmers.stackexchange.com. – Realm

About #2, its amazing the arbitrary code that people invent just because they decided. – Busch

I would argue that the definition of domain object doesn't have to be about objects that store data. "Objects" in OOP world contains both data and behaviors. In fact, Ward Cunningham lists "maintain business logic" as one of the feature of domain object. wiki.c2.com/?DomainObject. I understand you are illustrating that's how "many architectures" use domain object, but just wanted to clarify that it is not the standard definition (nor recommended usage as you pointed out). – Currie

@THISUSERNEEDSHELP Agreed. – Realm

Answer 2

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.

Transfiguration

I thought Business logic layer and Domain layer are different. I was reading Java Best practices by Oreilly and I came across this line :If your application naturally separates into standard layers (persistence, domain objects, business logic, presentation), you should consider using EJBs. So what is the difference between domain/business logic? – Panteutonism

It depends on how many layers you choose to build in your application. You might only have a two tier application, and you might have as many as six or seven different layers. – Valladolid

domain logic = business logic – Valladolid

Sorry if this is a vague question. But I am having trouble understanding Domain-objects and Domain Driven design concept. Agreed. If we consider the scenario of building a 4-layered software application with separate layers for presentation, business, domain object, business logic and persistence. How do I decide what forms domain and business logic? What are domain objects? And what is Domain-driven design? – Panteutonism

DDD is an approach to use when the domain is complex. If focuses on the core domain logic and the process that establishes a complex business model (ie. collaboration between programmers and domain experts). The domain logic refers to the general business rules, and the domain objects represents various real life business objects (person, loan, investors) that is involved in this domain logic. – Valladolid

@JørnE.Angeltveit This is the layer/tier that handles all the business logic - Layer and tier are different terms. Layer is logical separation with application and tier is a physical separation of system components. – Power

@niks: fair enough. I'm a big fan of being precise with terms, but AFAIKT, the sentence still make sense - even if you keep this differentiation in mind? – Valladolid

Answer 3

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.)

Incredulous

Answer 4

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.

Neper