Does CUBA Platform support Domain-Driven Design?
I don’t want to expose setters for every field I have.(I mean, i don’t want to use anemic domain models). I will have behavior in my domain model, when invoked, the state of the object will be changed.
For example, i will have an Account class which will have a getter for the field balance. I will not have setter for this. Instead, i will have two methods Debit(float amount) and Credit(float amount). They in turn change the value of balance. If I have a class like this, will the generated UI have options to perform these operations?
What you say can be easily achieved but beware: unless your behaviours are contained to the model itself you would end up injecting services into the model which will result in an unmanageable code pretty fast.
The most advanced Java framework on DDD is Apache Isis. You might take a look at the example todo app, or it’s estatio flagship product to get a feel about how that would go. Personally I find the model classes end up being bloated with lots of stuff unrelated among themselves which only commonality is the model they affect (there’s a thing called Mixins there to mitigate this) that might easily fit into separate services.
Imagine, following your example: you debit one account at the time that you credit another account. On which instance do you call the methods? You see you need some upper level in which to handle DebitHereAndDebitThere that makes sure all happens in one single db transaction (including balance checks).
On CUBA you would have simple models with simple methods (Debit and Credit) and put the logic into Services (DebitHereAndCreditThereWhileCheckingBalanceOrCredit [not a real method name]).