'Process Models' vs 'Data/Object Models' in MVC - oop

Question

Yes, another question on separation of responsibilities in an MVC architecture for a web application - I think this one has a subtle difference however...
My existing implementation looks like this:
Controllers: Very 'thin'; ASide from calls to Models & Views, Routing & Presentation Logic Only
Models: Very 'thick'; All Business Logic
Views: Very 'thin'; Aside from Content & Markup, Code is limited to Loops & Data Formatting
Additionally, the project utilizes an ORM as an abstraction layer above the database and 'Connectors' as wrapper classes to external services.
My question concerns the separation of responsibilities between models. For the most part, our Models mimic the 'things' within our system - 'Users', 'Products', 'Orders', etc.
I'm finding that this works quite well for serving simple data retrieval requests - the Controller(s) instantiate(s) the proper Model(s) & calls the relevant 'getter(s)'.
The issue arises when more complex processes are initiated such as 'PlaceOrder' or 'RegisterUser'. Sometimes these processes can be implemented within a single model, other times they require communication or coordination between models to implement.
As it stands, the Models communicate with each other directly in these cases rather than the process being managed by the Controller. Keeping the process within the Models seems proper (the Controller needn't be aware that a business rule of 'RegisterUser' requires a confirmation email to be sent, for instance).
What I'm finding with this implementation are two issues which concern me somewhat:
Models often seem to know too much about other Models - Models seem too tightly coupled in this implementation.
Methods within the Models are of two general types: 'getters/setters' and what I've taken to calling 'Process Methods', methods which manage a process, calling other methods within the Model or other Models as appropriate - these methods seem 'un-model-like', for lack of a better description.
Would it be appropriate to implement two sorts of Models - 'Data/Object Models' (populated primarily with 'getters/setters' and perhaps simple 'Process Methods' which are exclusively internal and 'Process Models' (populated with 'Process Methods' which require the collaboration of multiple ('Data/Object') Models)?
In this implementation, we'd have Models representing 'Users, 'Products', 'Orders' as well as 'Registration', 'Ordering', etc.
Thoughts?

Answer 1

The solution to this problem is to have a separate layer, a thin layer on top of Model. This layer is sometimes called the Service Layer or Application Layer. This layer does not too much of state, it rather calls various model methods and Data Access Methods.
For example, you may have one service class for managing orders.
class OrderService {
placeOrder(Order order) {
order.doModelStuff();
orderDao.save(order);
}
removeOrder(order){
order.cancel();
orderDao.delete(order);
...
}
or
class UserService {
registerUser(User user) {
if(userDao.userExists(user)) {
throw exception: user exists;
}
user.doRegistrationStuff();
userDao.save(user);
}
The methods in service layer are not confined to manipulate a single entity. In general, they can access and manipulate multiple models. For example,
placeOrder(Customer customer, Order order) {
customer.placeOrder(order);
save customer, if necessary.
save order, if necessary
customer.sendEmail();
Shipper shipper = new shipper;
shipper.ship(order, customer.getAddress());
...
}
The idea of this layer is that, its methods do a unit of work (typically corresponding to a single use case). This is in fact more of a procedural nature. You can read more about this layer from Martin Fowler, and others.
Note: my point is to show what a service/application layer is, not to show implementation of order, customer etc.

Answer 2

Martin Fowler, in his "Refactoring" book, seems to have the opinion that a "Data" model consisting of data, accessors, and nothing else, is a good candidate for refactoring into another class. He calls it "Data Class" in his library of "bad smells" in code.
That suggests it may be better to look at simplifying interactions between different processes, but allowing a process to be closely coupled to its own data
e.g. PlaceOrder and OrderData can be tightly coupled, but PlaceOrder involves a minimum of interactions such as AddOrderToCustomerRecord with the Customer process.

Answer 3

In design pattern terms, separating your model objects into simple objects (with getters and setters) and process objects (with process logic) would be turning your Domain Model into an Anemic Domain Model with Transaction Scripts.
You don't want to do that. Model objects telling each other to do things (your process methods) is good. That kind of coupling is preferable to the kind of coupling you get from using getters and setters.
Objects have to interact with each other, so there has to be some level of coupling. If you limit that coupling to methods that are meant to be exposed to the outside world (the object's API if you will), you can change the implementation of the object without side effects.
Once you expose implementation details (getters and setters expose object internals, which are implementation specific), you can't change the implementation without side effects. That's bad coupling. See Getters and Setters Are Evil for a more thorough explanation.
Back to your process methods and excessive coupling, there are ways to reduce coupling between model objects. Check the Law of Demeter for some guidelines on what is reasonable and what should be a red flag.
Also take a look at Domain Driven Design for patterns for reducing coupling. Something like an Aggregate Root can reduce coupling and complexity.
The tl;dr version: don't separate your data and methods, hide your data and only expose your API.