-Maypole model classes, and their own domain model. Without this distinction,\r
-developers may add domain-specific code to the Maypole model classes. To a\r
-certain extent, this is fine. But if you find yourself adding lots of\r
-non-Exported methods to your Maypole model classes, and these methods are not\r
-there to directly support Exported methods, consider whether you could separate\r
-out the domain model into a separate hierarchy of classes that you import into\r
-the Maypole model. See L<Maypole::Manual::Inheritance>.\r
-\r
-Otherwise, there will be two uncoupled code bases, living in the same files,\r
-interacting through a relatively small number of methods. These methods should\r
-in fact become the public API of the domain model, which should be moved to a\r
-separate class hierarchy.\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. See C<Presentation Model>. \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