Domain object dependencies when making them smarter

[rebornspirit]

I'm having the following problem. In a previous post I asked about how 'smart' domain object should be. Rod informed me that it was a bad design having domain objects that are just mindless drones...

So now I'm writing a new domain object with that information in mind and I'm having the following problem. Let me sketch the situation.

- When my domain object is generated a particular fields should be filled by a sequence number that is generated by another class thar provides this functionality.

So now I have two options:
- I generate this sequence number in my facade and set in manually on the domain object
- Or, I let the domain objects generate it manually upon creation, but by thoing that I need to create a dependency.

So, on one side I want to make my domain objects smarter ... but on the other hand I don't want to have those kind of dependencies.

So Rod, if you are reading this, perhaps you could clarify to what degree you can make domain objects smarter?

[Alarmnummer]

I'm having the following problem. In a previous post I asked about how 'smart' domain object should be. Rod informed me that it was a bad design having domain objects that are just mindless drones...

This anti-pattern is called Anemic Domain Model

So now I'm writing a new domain object with that information in mind and I'm having the following problem. Let me sketch the situation.

- When my domain object is generated a particular fields should be filled by a sequence number that is generated by another class thar provides this functionality.

So now I have two options:
- I generate this sequence number in my facade and set in manually on the domain object
- Or, I let the domain objects generate it manually upon creation, but by thoing that I need to create a dependency.

I think you have given a difficult example. With OR-mappers you don`t always have control on the structure of your objects and how id`s are created. I think in this case it would be better to keep the id-part outside of the domain object.

And another remark: it isn`t always a good thing to add all logic to that object. Sometimes it is better to seperate some aspects so you can group functionality and not data. Example: calculation of bonus for every employee-class. If you have a lot of such calculations, your classes are going to drown in the logic (they are going to be large) and the logic is scattered in a lot of classes (maintenance nightmare). In such cases it is better to seperate them.

An example of smarter domain objects:

interface Employee{
    int calcBonus();
}

class Ceo implements Employee{
    int calcBonus(){
       return 2*car.price()+1*office.price();
    }
}

class SimpleEmployee implements Employee{
    int calcBonus(){
         return yearsWorking()*100;
    }
}

You can also use something like this:

class BonusCalculator implements EmployeeVisitor{
   static int calc(Employee employee){
          EmployeeVisitor v = new EmployeeVisitor();
          employee.accepts(v);
          return v.amount;
   }

   int amount;

  void visit(Ceo c){
       amount = 2*c.getCar().price()+1*c.getOffice.price();
  }
 
  void visit(SimpleEmployee e){
       amount = e.yearsWorking()*100;
  }
}

[rebornspirit]

I think you have given a difficult example

That's way I'm posting it

In my opinion, logic like your calc example should indeed be inside the domain object. But when logic needs other classes (read dependencies) to perform its job, then I guess it is better to leave that part out of the domain object.

[Alarmnummer]

That's way I'm posting it

In my opinion, logic like your calc example should indeed be inside the domain object. But when logic needs other classes (read dependencies) to perform its job, then I guess it is better to leave that part out of the domain object.

Why? Because domain objects have difficulty getting dependencies? This is a well known problem and this is going to be solved in the next version of Spring. Or do you have another reason why domain objects should be kept stupid?

What if the CEO needs a dependency:

class Ceo implements Employee{    
     int calcBonus(){
       return 2*carPriceCalculator.calc(car)+1*office.price();
    }
}

The carPriceCalculator is responsible for calculating the current value of the car (the value depends on the age, how many miles it made, the color etc). Just because you need a dependency in the CEO you have to remove this logic from the Employees? This makes your design very fragile).

[rebornspirit]

Why? Because domain objects have difficulty getting dependencies?

Indeed, this is the only problem I have in mind of which I do not seem to have a good solution. Are there good approaches that I can use with this version of Spring, any suggestions?

What is going to be changed in Spring to address this kind of problem

Or do you have another reason why domain objects should be kept stupid?

Now raeson at all, in contrary

So what approach on layering are you taking, let me sketch teh design we have here:

dao
---
service
---
usecase
---
the mvc controller

The dao contains dao 'implemenations' like i.e. Hibernate, with the basic crud methods. No validation is done on this layer, i.e. the create method just creates the object it receives

The facade layer involved the validation process and the business logic, yes I know, ALL the business logic. This is definitly a design flow, but that's not something I introduced ... but I'm working on getting rid of it The facade layer calls the crud methods on the dao layer. Facade can wrap multiple facades

Our usecase layer is actually a representation of a particular use case. So the mvc controller has only access to one class, the injected use case layer instead of multiple facades.

The controller contain NO logic at all and get all their data from a single use case layer. On submission it retrieves the data from the form an passes it through to the use case layer for further handling.

[Alarmnummer]

Indeed, this is the only problem I have in mind of which I do not seem to have a good solution. Are there good approaches that I can use with this version of Spring, any suggestions?

What is going to be changed in Spring to address this kind of problem

Check this topic:
http://forum.springframework.org/showthread.php?t=19098

The facade layer involved the validation process and the business logic, yes I know, ALL the business logic. This is definitly a design flow, but that's not something I introduced ... but I'm working on getting rid of it The facade layer calls the crud methods on the dao layer. Facade can wrap multiple facades

This is a quite normal approach with Spring applications.

Our usecase layer is actually a representation of a particular use case. So the mvc controller has only access to one class, the injected use case layer instead of multiple facades.

I don`t have much experience with Model2 based webfameworks. So I can`t help you there.

The controller contain NO logic at all and get all their data from a single use case layer.

The Controller can contain logic: controller logic.

[rebornspirit]

The Controller can contain logic: controller logic.

Indeed, I was talking about 'business' logic ... my mistake

I'll have a look at DependencyInjectionInterceptorFactoryBean

Thx

[rebornspirit]

But I still find it very difficult to understand how or when to draw the line between logic that should be in the domain object and just too many dependencies (from your domain object to other layer)

I hat ethe thought of creating mindless domain object, but I also do not like the fact of too many dependencies.

I like to hear some more thoughts surrounding this topic

[Alarmnummer]

But I still find it very difficult to understand how or when to draw the line between logic that should be in the domain object and just too many dependencies (from your domain object to other layer)

I hat ethe thought of creating mindless domain object, but I also do not like the fact of too many dependencies.

I like to hear some more thoughts surrounding this topic

You could read: Domain Driven Design

[rebornspirit]

Hmmzz ... actually not a bad idea ... so I know now how I'm going to fill my weekend