1 Service per use-case, services are throw away implementations
-
Services call Commands - no logic in Services, no calling other services
-
Commands implement parts of use-cases and are thus re-usable
+
1 Service per use-case, should mostly delegate to Commands.
+
Commands implement use-cases or parts of it, and are thus reusable.
Subclass ResourceQuery and OrderQuery when implementing use-case specific
- querying
+ querying - this allows privilege checking.
+
+
One Transaction at a time - no TX inside of another TX.
+
Commands are added to TXs and performed on close: tx.addCommand(Command) and then tx.commitOnClose()
-
One Transaction at a time - no TX in TX
-
Commands are added to TXs and performed on close: tx.addCommand(Command)
Use tx.flush() and as late as possible in your TX tx.commitOnClose()
Only access ElementMaps if really no other way, mostly use tx.get*By(), tx.findBy()
and queries - if a specific get is missing, then add the method to StrolchTransaction and
send a pull request!
+
Don't write logic in REST API beans. Delegate to other classes, making your code reusable!
+
Transform to JSON using the StrolchElementToJsonVisitor.
+
References between objects is done by adding a ParameterBag with the id
+ relations to the object and then StringParameters with the value being the ID,
+ the UOM set to the type of element being referenced and the Interpretation set to the class type being
+ referenced.
+
<Activity Id="FromStock" Name="From Stock Template" Type="FromStock" TimeOrdering="Series">
-<ParameterBag Name="objectives" Id="Objectives" Type="Objectives">
- <Parameter Name="Duration" Id="duration" Value="PT1MS" Type="Duration" />
-</ParameterBag>
-
-<Action Id="Validate" Name="Validation of order" Type="Use" ResourceType="Validation" ResourceId="validation" />
-
-<!-- for each book we do a consume, i.e. reduce the stock quantity -->
-<Action Id="Consume" Name="Consume Template for book" Type="Template">
- <ParameterBag Id="parameters" Name="Parameters" Type="Parameters">
- <Parameter Id="quantity" Name="Quantity" Type="Float" Value="0" />
+ <ParameterBag Name="objectives" Id="Objectives" Type="Objectives">
+ <Parameter Name="Duration" Id="duration" Value="PT1MS" Type="Duration" />
</ParameterBag>
-</Action>
-<Action Id="Package" Name="Packaging of Order" Type="Use" ResourceType="Packaging" ResourceId="packaging" />
-<Action Id="Send" Name="Sending of package" Type="Use" ResourceType="Sending" ResourceId="sending" />
+ <Action Id="validate" Name="Validation of order" Type="Use" ResourceType="Validation" ResourceId="validation" />
+
+ <!-- for each book we do a consume, i.e. reduce the stock quantity -->
+ <Action Id="Consume" Name="Consume Template for book" Type="Template">
+ <ParameterBag Id="parameters" Name="Parameters" Type="Parameters">
+ <Parameter Id="quantity" Name="Quantity" Type="Float" Value="0" />
+ </ParameterBag>
+ </Action>
+
+ <Action Id="package" Name="Packaging of PurchaseOrder" Type="Use" ResourceType="Packaging" ResourceId="packaging" />
+ <Action Id="send" Name="Sending of package" Type="Use" ResourceType="Sending" ResourceId="sending" />
</Activity>
Let's explain a few things:
-
+
The Book entity is a Resource object and only contains the description and the
+ current quantity in stock.
+
+
The Account entity is a Resource and contains the address and further details of the user,
+ and with the user parameter the username is defined, thus referencing the real user.
+
+
The UserCart entity is a Resource and has a reference to the account Resource. Note how the
+ reference is done using a StringParameter, where Interpretation, UOM and the value is set in a specific
+ manner.
+
+
The UserCart entity is a Resource and references books using a special
+ ParameterBag with the type set to Book, the actual type of the book entity.
+ Each Parameter is of type Float and the ID of the parameter is the ID of the book, and the
+ value is the quantity that the user would like to purchase. There will only be one cart per
+ user/account.
+
+
The PurchaseOrder entity is an Order object, and is basically a copy of the
+ UserCart entity. This is the confirmed purchase order for the contents of a cart, and can then be used
+ for reports on how much of which book was sold.
+
+
The FromStock entity is an Activity object and defines the process we will go
+ through when delivering a purchase to a user. Note how the activity has a ParameterBag
+ objectives with a duration parameter. This defines globally for this activity
+ how long each Action should execute. This can be overridden in each Action and can help to
+ plan how much effort goes into the delivering of each PurchaseOrder.
+
+
Further note how the activity has three special actions (validate, package and
+ send) on which a ResourceType and ResourceId are defined. Actions
+ are always performed on a Resource, as the referenced Resource defines the behaviour of the action
+ through defined Policy objects.
+
+
For each book which will be purchased, an Action will be created of type Consume. In the
+ template this is defined by a template Action with the id Consume and will later be changed
+ accordingly.
+
Since we are referencing resources from actions in the activity, we need to add these as well, but not as
+ templates. They can be added to the defaultModel.xml file:
What should now be noted by these three new Resources is that they have Policy definitions:
+
+
ExecutionPolicy → defines how an action on this resource is executed by
+ referencing an ExecutionPolicy implementation.
+
+
ConfirmationPolicy → defines behaviour to be performed on every state change of
+ an action being performed on this resource by referencing an
+ ConfirmationPolicy implementation.
+
+
+
Currently these resources reference policies which don't exist. We will resolve this issue later, when we
+ implement the execution of the activity.
+
+
This concludes the model definition. In the next step we'll start creating services and commands for our
+ model.