updating figure filerefs

appendix_ds1_table.asciidoc

@@ -4,7 +4,7 @@
 
 [[recap_diagram]]
 .Our architecture by the end of the book
-image::images/maps_chapter_12_after.png[]
+image::images/apwp_1302.png[]
 
 // TODO: make a version without the yellow bits 
 

chapter_01_domain_model.asciidoc

@@ -13,7 +13,7 @@ always be able to find these little shapes at the core.
 
 [[maps_chapter_01_notext]]
 .A placeholder illustration of our domain model
-image::images/maps_chapter_01_notext.png[]
+image::images/apwp_0101.png[]
 
 
 === What Is a Domain Model?
@@ -125,7 +125,7 @@ to a customer's orders; see <<allocation_context_diagram>>.
 
 [[allocation_context_diagram]]
 .Context diagram for the allocation service
-image::images/allocation_context_diagram.png[]
+image::images/apwp_0102.png[]
 [role="image-source"]
 ----
 [plantuml, allocation_context_diagram]
@@ -472,7 +472,7 @@ class Batch:
 
 [[model_diagram]]
 .Our model in UML
-image::images/model_diagram.png[]
+image::images/apwp_0103.png[]
 [role="image-source"]
 ----
 [plantuml, model_diagram, config=plantuml.cfg]
@@ -980,7 +980,7 @@ def allocate(line: OrderLine, batches: List[Batch]) -> str:
 
 [[maps_chapter_01_withtext]]
 .Our domain model at the end of the chapter
-image::images/maps_chapter_01_withtext.png[]
+image::images/apwp_0104.png[]
 
 That'll probably do for now! We have a Domain Service which we can use for our
 first use case.   But first we'll need a database...

chapter_02_repository.asciidoc

@@ -14,7 +14,7 @@ a `Repository` object that sits between our Domain Model and the database.
 
 [[maps_chapter_02]]
 .Before and after Repository Pattern
-image::images/maps_chapter_02.png[]
+image::images/apwp_0201.png[]
 
 // TODO add a legend showing what the colours mean in the diagrams.  And
 // ideally some of the shapes and arrows and stuff too...
@@ -101,7 +101,7 @@ approach to structuring a system that has a UI, some logic, and a database (see
 
 [[layered_architecture2]]
 .Layered Architecture
-image::images/layered_architecture.png[]
+image::images/apwp_0002.png[]
 
 
 Django's Model-View-Template structure is closely related, as is
@@ -121,7 +121,7 @@ Instead, as discussed in the introduction, we'll think of our model as being on
 
 [[onion_architecture]]
 .Onion architecture
-image::images/onion_architecture.png[]
+image::images/apwp_0203.png[]
 [role="image-source"]
 ----
 [ditaa, onion_architecture]
@@ -173,7 +173,7 @@ storing the allocations as a collection on our `Batch` object.
 
 [[model_diagram_reminder]]
 .Our Model
-image::images/model_diagram.png[]
+image::images/apwp_0103.png[]
 // see chapter_01_domain_model for diagram source
 
 Let's see how we might translate this to a relational database.
@@ -570,7 +570,7 @@ an illustration.
 
 [[repository_pattern_diagram]]
 .Repository pattern
-image::images/repository_pattern_diagram.png[]
+image::images/apwp_0205.png[]
 [role="image-source"]
 ----
 [ditaa, repository_pattern_diagram]
@@ -922,7 +922,7 @@ complexity, local simplicity], by Rob Vens)]
 
 [[domain_model_tradeoffs_diagram]]
 .Domain Model tradeoffs as a diagram
-image::images/domain_model_tradeoffs_diagram.png[]
+image::images/apwp_0206.png[]
 [role="image-source"]
 ----
 [ditaa, domain_model_tradeoffs_diagram]

chapter_03_abstractions.asciidoc

@@ -47,7 +47,7 @@ We can reduce the degree of coupling within a system
 
 [[coupling_illustration1]]
 .Lots of coupling
-image::images/coupling_illustration1.png[]
+image::images/apwp_0301.png[]
 [role="image-source"]
 ----
 [ditaa,coupling_illustration1]
@@ -63,7 +63,7 @@ image::images/coupling_illustration1.png[]
 
 [[coupling_illustration2]]
 .Less coupling
-image::images/coupling_illustration2.png[]
+image::images/apwp_0302.png[]
 [role="image-source"]
 ----
 [ditaa,coupling_illustration2]

chapter_04_service_layer.asciidoc

@@ -6,7 +6,7 @@ got to at the end of the Repository chapter:
 
 [[maps_service_layer_before]]
 .Before: we drive our app by talking to Repositories and the Domain Model
-image::images/maps_chapter_04_before.png[]
+image::images/apwp_0401.png[]
 
 
 In this chapter, we discuss the difference between orchestration logic,
@@ -29,7 +29,7 @@ NOTE: In our diagrams, we are using the convention that the _yellow/orange_
 
 [[maps_service_layer_after]]
 .The Service Layer will become the main way into our app
-image::images/maps_chapter_04_after.png[]
+image::images/apwp_0402.png[]
 
 
 [TIP]
@@ -780,7 +780,7 @@ and the `AbstractRepository` (the port, in ports & adapters terminology).
 
 [[service_layer_diagram_abstract_dependencies]]
 .Abstract dependencies of the service layer
-image::images/service_layer_diagram_abstract_dependencies.png[]
+image::images/apwp_0403.png[]
 [role="image-source"]
 ----
 [ditaa, service_layer_diagram_abstract_dependencies]
@@ -803,7 +803,7 @@ adapter):
 
 [[service_layer_diagram_test_dependencies]]
 .Tests provide an implementation of the abstract dependency
-image::images/service_layer_diagram_test_dependencies.png[]
+image::images/apwp_0404.png[]
 [role="image-source"]
 ----
 [ditaa, service_layer_diagram_test_dependencies]
@@ -834,7 +834,7 @@ And when we actually run our app, we swap in the "real" dependency,
 
 [[service_layer_diagram_runtime_dependencies]]
 .Dependencies at runtime
-image::images/service_layer_diagram_runtime_dependencies.png[]
+image::images/apwp_0405.png[]
 [role="image-source"]
 ----
 [ditaa, service_layer_diagram_runtime_dependencies]

chapter_05_high_gear_low_gear.asciidoc

@@ -144,7 +144,7 @@ important to understand the trade-off between coupling and design feedback (see
 
 [[test_spectrum_diagram]]
 .The test spectrum
-image::images/test_spectrum_diagram.png[]
+image::images/apwp_0501.png[]
 [role="image-source"]
 ----
 [ditaa, test_spectrum_diagram]

chapter_06_uow.asciidoc

@@ -16,7 +16,7 @@ layer to start a session, it talks to the repository layer to initialize a
 
 [[before_uow_diagram]]
 .Without UoW: API talks directly to 3 layers
-image::images/maps_chapter_05_before.png[]
+image::images/apwp_0601.png[]
 
 <<after_uow_diagram>> shows our target state: the Flask API now only does two
 things: it initializes a Unit of Work, and it invokes a service.  The service
@@ -27,7 +27,7 @@ to talk directly to the DB.
 
 [[after_uow_diagram]]
 .With UoW: UoW now manages DB state
-image::images/maps_chapter_05_after.png[]
+image::images/apwp_0602.png[]
 
 And we'll do it all using a lovely piece of Python syntax, a context manager.
 

chapter_07_aggregate.asciidoc

@@ -14,7 +14,7 @@ the old `allocate()` domain service available as a method on Product instead.
 
 [[maps_chapter_06]]
 .Adding the Product Aggregate
-image::images/maps_chapter_06.png[]
+image::images/apwp_0701.png[]
 
 
 Why?  Let's find out.
@@ -228,7 +228,7 @@ the world and passing them to the `allocate()` domain service...
 
 [[before_aggregates_diagram]]
 .Before: allocate against all batches using domain service
-image::images/before_aggregates_diagram.png[]
+image::images/apwp_0702.png[]
 [role="image-source"]
 ----
 [plantuml, before_aggregates_diagram, config=plantuml.cfg]
@@ -278,7 +278,7 @@ instead.
 
 [[after_aggregates_diagram]]
 .After: ask Product to allocate against its batches
-image::images/after_aggregates_diagram.png[]
+image::images/apwp_0703.png[]
 [role="image-source"]
 ----
 [plantuml, after_aggregates_diagram, config=plantuml.cfg]
@@ -538,7 +538,7 @@ with `version=4`, and the other update will be rejected.
 
 [[version_numbers_sequence_diagram]]
 .Sequence Diagram: Two Transactions Attempt a Concurrent Update on Product
-image::images/version_numbers_sequence_diagram.png[]
+image::images/apwp_0704.png[]
 [role="image-source"]
 ----
 [plantuml, version_numbers_sequence_diagram, config=plantuml.cfg]

chapter_08_events_and_message_bus.asciidoc

@@ -31,7 +31,7 @@ as previewed in <<message_bus_diagram>>.
 
 [[message_bus_diagram]]
 .Events flowing through the system
-image::images/maps_chapter_07.png[]
+image::images/apwp_0801.png[]
 
 // TODO: add before diagram for contrast (?)
 

chapter_09_all_messagebus.asciidoc

@@ -8,15 +8,15 @@ side-effect...
 
 [[maps_chapter_08_before]]
 .Before: the message bus is an optional add-on
-image::images/maps_chapter_08_before.png[]
+image::images/apwp_0901.png[]
 
 ...to the situation in <<map_chapter_08_after>> where
 everything goes via the message bus, and our app has been transformed
 fundamentally into a message-processor.
 
 [[map_chapter_08_after]]
 .The Message Bus is now the main entrypoint to the service layer
-image::images/maps_chapter_08_after.png[]
+image::images/apwp_0902.png[]
 
 
 [TIP]
@@ -62,7 +62,7 @@ model elaboration.], we model the situation as in
 
 [[batch_changed_events_flow_diagram]]
 .batch quantity changed means deallocate and reallocate
-image::images/batch_changed_events_flow_diagram.png[]
+image::images/apwp_0903.png[]
 [role="image-source"]
 ----
 [ditaa, batch_changed_events_flow_diagram]
@@ -485,7 +485,7 @@ back to our existing handler for allocation, to be re-allocated.
 
 [[reallocation_sequence_diagram]]
 .Sequence diagram for reallocation flow
-image::images/reallocation_sequence_diagram.png[]
+image::images/apwp_0904.png[]
 [role="image-source"]
 ----
 [plantuml, reallocation_sequence_diagram, config=plantuml.cfg]

chapter_11_external_events.asciidoc

@@ -21,7 +21,7 @@ there as well.
 
 [[message_processor_diagram]]
 .Our application is a Message Processor
-image::images/maps_chapter_10.png[]
+image::images/apwp_1101.png[]
 
 
 [TIP]
@@ -52,7 +52,7 @@ we've named our system after a noun, _batches_, instead of _allocation_).
 
 [[batches_context_diagram]]
 .Context diagram for the "batches" service
-image::images/batches_context_diagram.png[]
+image::images/apwp_1102.png[]
 [role="image-source"]
 ----
 [plantuml, batches_context_diagram, config=plantuml.cfg]
@@ -84,7 +84,7 @@ order, we want to update the customer record to flag them as a VIP.
 
 [[command_flow_diagram_1]]
 .Command Flow 1
-image::images/command_flow_diagram_1.png[]
+image::images/apwp_1103.png[]
 [role="image-source"]
 ----
 [plantuml, command_flow_diagram_1, config=plantuml.cfg]
@@ -160,7 +160,7 @@ should own this process, as shown in <<command_flow_diagram_2>>?
 
 [[command_flow_diagram_2]]
 .Command Flow 2
-image::images/command_flow_diagram_2.png[]
+image::images/apwp_1104.png[]
 [role="image-source"]
 ----
 [plantuml, command_flow_diagram_2, config=plantuml.cfg]
@@ -201,7 +201,7 @@ right after we take a user's order for 3 MISBEGOTTEN-RUG,
 
 [[command_flow_diagram_with_error]]
 .Command Flow with Error
-image::images/command_flow_diagram_with_error.png[]
+image::images/apwp_1105.png[]
 [role="image-source"]
 ----
 [plantuml, command_flow_diagram_with_error, config=plantuml.cfg]
@@ -329,7 +329,7 @@ Our new flow will look like this:
 
 [[reallocation_sequence_diagram_with_redis]]
 .Sequence diagram for reallocation flow
-image::images/reallocation_sequence_diagram_with_redis.png[]
+image::images/apwp_1106.png[]
 [role="image-source"]
 ----
 [plantuml, reallocation_sequence_diagram_with_redis, config=plantuml.cfg]

chapter_12_cqrs.asciidoc

@@ -9,7 +9,7 @@ but hopefully we can make the argument that it's not _totally_ unreasonable.
 
 [[maps_chapter_11]]
 .Separating reads from writes
-image::images/maps_chapter_11.png[]
+image::images/apwp_1201.png[]
 
 <<maps_chapter_11>> shows where we might end up. Firstly though, why bother?
 
@@ -675,7 +675,7 @@ to update the read model, which the GET/read operation can use.
 
 [[read_model_sequence_diagram]]
 .Sequence diagram for read model
-image::images/read_model_sequence_diagram.png[]
+image::images/apwp_1202.png[]
 [role="image-source"]
 ----
 [plantuml, read_model_sequence_diagram, config=plantuml.cfg]

chapter_13_dependency_injection.asciidoc

@@ -21,14 +21,14 @@ of our main dependency, the UoW.
 
 [[bootstrap_chapter_before_diagram]]
 .Without bootstrap: entrypoints do a lot
-image::images/maps_chapter_12_before.png[]
+image::images/apwp_1301.png[]
 
 <<bootstrap_chapter_after_diagram>> shows our bootstrapper taking over those
 responsibilities.
 
 [[bootstrap_chapter_after_diagram]]
 .Bootstrap takes care of all that in one place
-image::images/maps_chapter_12_after.png[]
+image::images/apwp_1302.png[]
 
 
 === Implicit vs Explicit Dependencies

introduction.asciidoc

@@ -40,7 +40,7 @@ https://thedailywtf.com/articles/Enterprise-Dependency-Big-Ball-of-Yarn].
 
 [[bbom_image]]
 .A real-life dependency diagram
-image::images/big_ball_of_yarn.jpg[]
+image::images/apwp_0001.png[]
 
 TIP: Big ball of mud is the natural state of software in the same way that wilderness
     is the natural state of your garden. It takes energy and direction to
@@ -173,7 +173,7 @@ One of the most common examples is the _three layered architecture_ shown in
 
 [[layered_architecture1]]
 .Layered architecture
-image::images/layered_architecture.png[]
+image::images/apwp_0002.png[]
 [role="image-source"]
 ----
 [ditaa,layered_architecture]

part1.asciidoc

@@ -47,7 +47,7 @@ yet!  We introduce each box in the figure, one by one.
 
 [[part1_components_diagram]]
 .A component diagram for our app at the end of Part 1
-image::images/part1_components_diagram.png[]
+image::images/apwp_p103.png[]
 
 //TODO: inline this diagram's source.
 //TODO: font size too small?

part2.asciidoc

@@ -21,7 +21,7 @@ diagram, <<allocation_context_diagram_again>>.
 
 [[allocation_context_diagram_again]]
 .But exactly how will all these different systems talk to each other?
-image::images/allocation_context_diagram.png[]
+image::images/apwp_0102.png[]
 
 
 // TODO (DS): Up until this point you haven't really said much about how this