CODEWITHSUNDEEP
domain-driven-designmicroservicesbusiness-logic
Nayab Siddiqui
Nayab Siddiqui

Reputation: 2151

Are all the classes containing business logic, domain objects?

So I have few doubts regarding calling something as domain object (and eventually placing the class under domain package) or not.

I have a micro-service whose responsibility is to do some calculations (without getting into actual business requirements, all it does is calculate some return of intereset based on given request). Now to achieve the calculations there are certain sub-calculations which need to take place and hence are composed in different classes respectively. But yes, these calculation do not need to be persisted in DB , and neither they have an ID (so definitely not an Entity or Aggregate). However these individual calculator classes (for the lack of terminology) do contain some complex business logic. Now, my question is, do these individual classes still qualify/classify as domain objects or should they be referred to as services ?

Feel free to ask for more clarifications around use case if need be.

Cheers !

Upvotes: 4

Views: 1273

Answers (3)

James
James

Reputation: 31

A simple test could be asking below questions -

Does your “calculator” (as you refer it) hold the calculation result as an immutable state? — if the answer is yes then it is a Value Object.

Is the “Calculator” stateless and only exposes a “calculate” behaviour which accepts a request & returns a calculation result? — if the answer is yes then it is a Service, however, the “result” returned by this service may be classified as Value Object.

Upvotes: 3

mgonzalezbaile
mgonzalezbaile

Reputation: 1086

I would say that your calculations can fit well either in Value Objects or Domain Services.

How to differentiate? Well, I understand Domain Services as services (well, obvious) with business logic (such as your calculations) that require some kind of external dependency you need to inject in order to get your logic work.

On the other hand, if you can name that business logic as a business concept (i.e. CustomerFee, CustomerCommission, etc) and you don't need any injected dependency to make it work I would say it's a Value Object.

For instance, imagine that you want to calculate the price of a reservation which depends on the fee you will charge to the customer (among other params):

ReservationPrice(CustomerFee customerFee, ItemPrice ItemPrice)

Now your CustomerFee is also calculated based on (say any variable) something.

This way you are modeling your calculations just with Value Objects which allows you to show in your code all the different business concepts they depend on. Also anyone looking at your code and files structure can get an idea about what you are calculating.

Upvotes: 2

Constantin Galbenu
Constantin Galbenu

Reputation: 17683

Now, my question is, do these individual classes still qualify/classify as domain objects or should they be referred to as services

From the DDD point of view, in the Domain layer, there are the following terms that could be implemented using classes: Domain entities, Aggregate roots (a type of Domain entity), Value objects and Domain services.

Because your things don't have an Identity they cannot be Domain entities or Aggregate roots. Calculations could be done inside Value objects or Domain services. Value objects contain specific behavior related to values so most probable your calculations are implemented using Domain services.

From my experience, not every domain class must be a DDD building block, they could be just classes extracted for better maintainability, Single responsibility principle (SOLID in general) etc.

Upvotes: 7

Related Questions