-However, in many applications, a more complex domain model is required, or may \r
-already exist. In this case, the Maypole model is more clearly seen as a layer \r
-that sits on top of the custom domain model, and controls access to it from \r
-the web UI. In this kind of situation, it seems more helpful to think of the \r
-Maypole model as part of the controller. This conceptualisation helps developers \r
-maintain a separation between the Maypole model classes, and their own domain \r
-model. Without this distinction, developers may add domain-specific code \r
-to the Maypole model classes, ending up with two separate code bases \r
-intermingled within one set of files. \r
-\r
-To a certain extent, this is fine. But if you find yourself adding lots on \r
-non-Exported methods to your Maypole model classes, \r
-and these methods are not there to support Exported methods, consider whether \r
-you could separate out the domain model into a separate hierarchy of classes \r
-that you import into the Maypole model. \r
-\r
-The distinction between the Maypole model, the domain model, and the model in \r
-the MVC pattern, is fuzzy and variable. In straightforward Maypole applications, \r
-they're all pretty much the same thing. In more advanced applications, they \r
-begin to diverge. Take care out there. \r
-\r
-=item view\r
-\r
-This is represented in Maypole by the view class (L<Maypole::View::TT>, \r
-L<Maypole::View::Mason>, or L<MasonX::Maypole::View>), and by the templates. \r
-\r
+However, in many applications, a more complex domain model is required, or may\r
+already exist. In this case, the Maypole model is more clearly seen as a layer\r
+that sits on top of the domain model, mediating access to it from the web UI, \r
+via the controller.\r
+\r
+This conceptualisation helps developers maintain a separation between the\r
+Maypole model classes (presentation model), and the domain model. Without this\r
+distinction, developers may add domain-specific code to the Maypole model\r
+classes. To a certain extent, in simple applications, this is fine. But if you\r
+find yourself adding lots of non-Exported methods to your Maypole model classes,\r
+and these methods are not there to directly support Exported methods, consider\r
+whether you could separate out the domain model into a separate hierarchy of\r
+classes - see L<Maypole::Manual::Inheritance>.\r
+\r
+Otherwise, the 'model' classes may develop into two quite uncoupled code bases,\r
+but which co-exist in the same files. They will interact through a relatively\r
+small number of methods. These methods should in fact become the public API of\r
+the domain model, which should be moved to a separate class hierarchy. At some\r
+point, the convenience of dropping new methods into the 'shared' classes will be\r
+outweighed by the heuristic advantage of separating different layers into\r
+separate class hierarchies.\r