anchor.diff:  This is great to act as the starting point for identifying new stories; later on when the feature is being implemented, the same fixture script can be re-used within that feature's integration tests.
   (More on tests later).
   
  -image::https://raw.githubusercontent.com/apache/isis/master/antora/toc/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/020-install-fixtures.png[link="https://raw.githubusercontent.com/apache/isis/master/antora/toc/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/020-install-fixtures.png"]
  +image::https://raw.githubusercontent.com/apache/isis/master/antora/components/docs/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/020-install-fixtures.png[link="https://raw.githubusercontent.com/apache/isis/master/antora/components/docs/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/020-install-fixtures.png"]
   
   === Dashboard and View Models
   
   Most of the time the end-user interacts with representations of persistent domain entities, but Isis also supports view models which can aggregate data from multiple sources.
   The todoapp example uses a "dashboard" view model to list todo items not yet done vs those completed.
   
  -image::https://raw.githubusercontent.com/apache/isis/master/antora/toc/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/030-dashboard-view-model.png[link="https://raw.githubusercontent.com/apache/isis/master/antora/toc/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/030-dashboard-view-model.png"]
  +image::https://raw.githubusercontent.com/apache/isis/master/antora/components/docs/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/030-dashboard-view-model.png[link="https://raw.githubusercontent.com/apache/isis/master/antora/components/docs/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/030-dashboard-view-model.png"]
   
   In general we recommend to initially focus only on domain entities; this will help drive out a good domain model.
   Later on view models can be introduced in support of specific use cases.
  
positive.code: These same fixture scripts can be reused within integration tests.
  For example, the code snippet below shows how the `FixtureScripts` service injected into an integration test can then be used to set up data:
  
  image::https://raw.githubusercontent.com/apache/isis/master/antora/toc/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/210-fixture-scripts.png[link="https://raw.githubusercontent.com/apache/isis/master/antora/toc/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/210-fixture-scripts.png"]
  
  The tests themselves are run in junit.
  While these are integration tests (so talking to a real database), they are no more complex than a regular unit test:
  
  image::https://raw.githubusercontent.com/apache/isis/master/antora/toc/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/220-testing-happy-case.png[link="https://raw.githubusercontent.com/apache/isis/master/antora/toc/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/220-testing-happy-case.png"]
  
  
  To simulate the business rules enforced by Apache Isis, the domain object can be "wrapped" in a proxy.
  For example, if using the Wicket viewer then Apache Isis will enforce the rule (implemented in the `ToDoItem` class itself) that a completed item cannot have the "completed" action invoked upon it.
  The wrapper simulates this by throwing an appropriate exception:
  
  image::https://raw.githubusercontent.com/apache/isis/master/antora/toc/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/230-testing-wrapper-factory.png[link="https://raw.githubusercontent.com/apache/isis/master/antora/toc/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/230-testing-wrapper-factory.png"]
  
  
  
  
negative.code: Another important tool to ensure your codebase remains maintainable is Isis' internal event bus.
  It is probably best explained by example; the code below says that the "complete" action should emit a `ToDoItem.Completed` event:
  
  image::https://raw.githubusercontent.com/apache/isis/master/antora/components/docs/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/240-domain-events.png[link="https://raw.githubusercontent.com/apache/isis/master/antora/components/docs/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/240-domain-events.png"]
  
  Domain service (application-scoped, stateless) can then subscribe to this event:
  
  image::https://raw.githubusercontent.com/apache/isis/master/antora/components/docs/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/250-domain-event-subscriber.png[link="https://raw.githubusercontent.com/apache/isis/master/antora/components/docs/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/250-domain-event-subscriber.png"]
  
  And this test verifies that completing an action causes the subscriber to be called:
  
  image::https://raw.githubusercontent.com/apache/isis/master/antora/components/docs/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/260-domain-event-test.png[link="https://raw.githubusercontent.com/apache/isis/master/antora/components/docs/modules/ROOT/images/what-is-apache-isis/isis-in-pictures/260-domain-event-test.png"]
  
  In fact, the domain event is fired not once, but (up to) 5 times.
  It is called 3 times prior to execution, to check that the action is visible, enabled and that arguments are valid.
  