Whenever I read an article about modern design pattern like MVVM or DDD I have trouble translating the example into the domains I am typically working on.
All these pattern come to the conclusion that domain models should exist in their own little bubble with no references to anything whatsoever, should not be exposed to the view for binding, should be POCOs/POJOs and contain the "business logic".
The question I always ask myself is: What should the domain model do then?
The answer is obviously "Handle business logic", but when I think about what that might be I'm having trouble finding real world examples.
For example: One typical example that always comes up are financial applications, where you could have a BankAccount entity which could have a TransferMoneyTo(otherAccount) function.
This sounds good in theory, but in the real world this application would not manage all the bank accounts of the world, but just accounts of one bank.
Therefore a real world application would have to somehow contact the other bank's server to initiate this transaction. This "somehow" is obviously a service to which the BankAccount is not allowed to have a reference to. This means that this would not be a very good example for an isolated domain model.
So far all examples I have read about where either like this, where the example only worked, because it neglected important details or trivial. By trivial I mean, the "business logic" just consisted of simple validation (e.g. required fields).
All this leads to an anemic domain model (apart from validation perhaps), which is supposed to be a bad thing.
My question is: What hides behind the term "business logic" apart from validation, that would justify the need for a separate domain model?
Note: I know this depends on the domain you are working on, but I think at least some example where DDD would be actually useful would be appreciated.
What hides behind the term "business logic"
A lot of domain models reflect business processes and thus contain state machines, where you can transition things from a known valid state to another according to some rules. You get this kind of process in just about every business. Other domains can involve more complex internal algorithms and data transformations.
These hardly fall into the simplistic "just validation" category, unless you consider a railway company seat reservation system or a government's tax calculation process as "validation".
This "somehow" is obviously a service to which the BankAccount is not allowed to have a reference to
Regarding domains communicating with the outside world, it's not really their responsibility. Generally what you have is the domain emitting an event saying "this happened !" and the applicative context handles it and initiates the appropriate communications with external systems.
Orchestrating calls to internal and external subsystems so that data flows in, out and through an application is not domain logic, it's a technical application-level concern. Inversion of Control, in one form or another (events, DI, etc.), is usually key to keeping the domain unaware of this.