Implementation Specification
Planned Order Implementation
-
Table of Contents
  Environment: Planned Order Domain
A set of Bounded Context implemented to support the selection of parts and an order.
Notes: This environment will be built and deployed in a Express/Nodejs back end and a MySql Database Using Sequelize ORM -
  Customer
  Part (pr)
  Full Sales Order (pu)
  Available Parts List (pr)
  Parts Category Items (pr)
  Order Total Costs

  Environment: Planned Order Front End
This environment will implemented with a React and React Bootstrap framework.
Notes: The Document Object Model in the Browser. Implemented with HTML and scripts -
  Planned Order
  Submitted Order
  Parts Filter


Introduction
A set of assertions to be implemented as bounded contexts. The implementation is intended to proof the abiity of Assertum to provide requirements ( a set of instructions to developers) that can be implemented as bounded contexts.

Notes:
There are 9 assertions identified to be implemented in the Planned Order V05 NuVisum environment.

There are 4 that would be implemented as Bindable Component Entities (OE06 Part, Oe04 - Customer, OE18r - Available Parts List, and OE29 - Parts Category Items). These can be tested with Postman.

There are 3 assertions that represent the interaction with the User OE07, OE11, and OE10. These would be implemented in HTML(or other front end approach), probably in one UI available for the Customer with a Customer ID identified ( perhaps by presenting a token)

There is 1 assertion that is a business rule. It is calculated automatically but should be implemented in the UI. The alternative would be to implement it as business logic in an aggregate also delivering OE12.

There is 1 assertion (OE12 - Full Sales Order) that would be implemented in a Bindable Component Aggregate to receive the submission of an order from a customer.

As a user acceptance the tester should be able to take the role of an individual browser.

In the UI, a Customer should be able to open up the Client UI in a browser, set some filters to see available parts, select one or more and add to the cart. They should be able to see what they have in the cart and remove items as needed. If they leave their planned they will not be able to find their planned order on reentering. This capability will require an additional entity.

Using the Specifications
Each assertion to be implemented are included below.
Each includes a set of values to show the information needed to implement them.
The SpecID and Name identify the Assertion. On the right the Activity Type is shown. A RETRIEVAL indicates information to be pulled from a persistent entity.
A summary of the assertion is shown and a Specification to more formally explain the implementation.
Model Note and Implementation Note elaborate further.
The structure of the information produced by the implemented assertion is shown in the output values attributes (they include an example value to clarify understanding).
When an assertion requires input information, that too is shown as attributes.
All of this text information is repeated below in a JSON format. It can be used to define record structures for persistence.

This Version 05 of the specifications should be all that is needed for a developer to put together a working implementation that can be used to refine subsequent versions of the structure of specifications.



-
 
Specification: OE04 - Customer RETRIEVAL
This Implementation:
CustD

Retrieve Customer details for a given Customer ID. Implemented in Customer Entity. Initiated by the Planned Order UI.
Specification:
Method: GET GetCustomerDetailsForCustomerID Return a single record for a Customer

Model Note: This retrieval is used to add the customer address when they make an order.
This can be simply tested using PostMan with a customerID.

Implementation Note: For the NV environment this is seen as an Entity that shows all Customers. And an SQL query for a CustomerID.


UI Note: None Automatic

As a Sales Manager I want to determine and provide: Customer so that subsequent decisions can be made.
-
Solution must calculate 4 output values for the following:
 
First Name ---[Customer First name] null
Example value:
Mo
 
Customer Number ---[Unique identity for external identification] STRING
Example value:
PPC342
 
Last Name ---[Customer last name] STRING
Example value:
Jones
 
Full Address ---[Delivery address to support courier delivery. Validation: text to identify location. ] STRING
Example value:
1234 Any St., Ohioville, PA

 
Specification: OE06 - Part (pr) RETRIEVAL
This Implementation:
-

Retrieve details about the Part to support the Planned Order UI. -- An Entity retrieval. -- Initiated from Parts Filter UI
Specification:
Method: POST: GetDetailsForPartIDs- Return all parts details for the PartID

Model Note: Although automatic, the Catalog Manager is responsible for maintining the catalog and this assertion that deliivers it.
This is a second retrieval from the Parts Entity (similar to OE18r)
This retrieves by PartIDs.
This can be simply tested using PostMan with a filter. The filter is provided in the body of the HTTP request.
This is used by Planned Order using a PULL connection.

Implementation Note: For the NV environment this is seen as an Entity that shows all products. And an assembled SQL query.

UI Note: None: Automatic.

As a Catalog Manager I want to determine and provide: Part (pr) so that subsequent decisions can be made.
-
Solution must calculate 6 output values for the following:
 
productid ---[Internal UUID for persistent integrity] UUID
Example value:
43099&99aj
 
categoryId ---[Category for filtering. Vallidation: Must be listed in the Category Entity ] STRING
Example value:
3099u75i3
 
Part Description(description) ---[Semi structured narrative of use of part and installation details.] STRING
Example value:
A wing mirror that can be fitted to any vehicle.
 
unitPrice ---[Price in CAD. Validation: Must be dollar amount. Validation: Cannot be set to zero.] CURRENCY
Example value:
12.99
 
SKU ---[Stock Keeping Unit. Identifier, unique within this organization. Validation: Must be unique. Integer ascending by datetime.] STRING
Example value:
3387
 
Name ---[Short identifying name to support search and match to physical product. Validation: Unique within Products. ] STRING
Example value:

 
Specification: OE07 - Planned Order CONFIGURATION
This Implementation:
-

A collection of Planned Part Items for a Customer. Implemented in the UI and used to determine total costs.
Specification:
The Customer must inspect the Product Catlog in order to determine Product capabilities, fit, and prices. For this Simple example we assume they have a way of inspecting available parts subsetted by category items. ---Customer must decide to add an order item to the Planned Order (they have not comitted to buy yet). They can submit this information to the business rule that automatically determines total costs and shipping.

Model Note: This is a list of Products and quantities that a customer intends to order.

For Assertum this is a complex type and needs some additional finishing of the types concept.

TBD: The frame needs compex types.


Implementation Note: Probably part of the HTML...

UI Note: Provide the ability to filter the full product catalog by category.

As a Customer(Sales) I want to determine and provide: Planned Order so that subsequent decisions can be made.
-
Solution must present values from the following Assertions to support the decision:
  OE06 ---Part (pr)
    DIRECT (null)
    Connection Note:     fdsadsfdsa
-
  productid      Internal UUID for persistent integrity
(             sample value:      43099&99aj)
  categoryId      Category for filtering. Vallidation: Must be listed in the Category Entity
(             sample value:       3099u75i3)
  Part Description(description)      Semi structured narrative of use of part and installation details.
(             sample value:      A wing mirror that can be fitted to any vehicle.)
  unitPrice      Price in CAD. Validation: Must be dollar amount. Validation: Cannot be set to zero.
(             sample value:       12.99)
  SKU      Stock Keeping Unit. Identifier, unique within this organization. Validation: Must be unique. Integer ascending by datetime.
(             sample value:      3387 )
  Name      Short identifying name to support search and match to physical product. Validation: Unique within Products.
(             sample value:       )
  OE18r ---Available Parts List (pr)
    IMPL1 (null)
    Connection Note:     Retrieve the available parts using the property of partsFilter (an array of CategoryItems). This will be delivered with the Message Moderator.
-
  PartID      Interchangable ID
(             sample value:       PPP334)
  UnitPrice      Price as of start of Cart
(             sample value:       $45.00)
  ShortDescription      Short Description by PP
(             sample value:       Brake Pad for Truck)
  PartUUID      EntityID
(             sample value:       part1)
  PartName      -- New Desc --
(             sample value:       BrakeMaster)
-
Solution must provide 6 input entry fields to capture the following:
 
Product ID ---[ Populated from the part selected. Validation: Must be in the Product list] STRING
Example value:
PPP23
 
Quantity ---[ Stated by the shopper. Validation: Orders over 100 of one part are not allowed.] STRING
Example value:
6
 
Price ---[ Populated from the part selected. Validation: must be the price in the Product Catalog The unit price of the part when added to cart.] STRING
Example value:
$41.89
 
orderId ---[The cart these items belong to. Validation: auto generated on creation.] STRING
Example value:
(*98&88YT
 
customerId ---[Internal UUID for customer. Validation: auto generated on creation.] UUID
Example value:
(8778J7&*
 
Context_UserToken ---[ A token that controls access to the cubicle and the messages it manages] STRING
Example value:
33098&9775

 
Specification: OE11 - Submitted Order INTENT
This Implementation:
trialdesc2

Submit the decision to purchase an Order and its Items.
Specification:
Populate the Shipping details from the Customer Record and and the current order from Planned Order. The customer is presented with the full details of the order and committs with an acceptance (contractural).

Model Note: An interesting assertion. Might be only an emit.

This is the sales order as it is persisted. It is necessary that the order have automatic business rules applied before it is persisted. This is a business decision. The alternative is that the BR is applied on retrieval. An interesting design point.And this is interesting because it might be modeled with a recursive business rule but the assertion should not emit unless fully populated.If this is customer it is only items and not populated??Once comitted by customer it is persisted. (when received by pu)This is manual because the customer has to inspect it to make the comittment (contractural acceptance).

Implementation Note:

UI Note:

As a Customer(Sales) I want to determine and provide: Submitted Order so that subsequent decisions can be made.
-
Solution must present values from the following Assertions to support the decision:
  BR02 ---Order Total Costs
    null (null)
    Connection Note:     Available from business rule applied to order items.
-
  Total Ordered Items      Sum of quantity * unit price
(             sample value:      $5234)
  Shipping      10% (if total is > $1000 - 8%)
(             sample value:       $320)
  Total With Shipping      -- New Desc --
(             sample value:       $5789)
  Tax      5%
(             sample value:       $289)
  Total Payable      Items + Shipping + Tax
(             sample value:       $5976)
  OE04 ---Customer
    DBSTORE (PULL)
    Connection Note:     Retrieve Customer details for a Customer ID
-
  First Name      Customer First name
(             sample value:      Mo )
  Customer Number      Unique identity for external identification
(             sample value:       PPC342)
  Last Name      Customer last name
(             sample value:       Jones)
  Full Address      Delivery address to support courier delivery. Validation: text to identify location.
(             sample value:       1234 Any St., Ohioville, PA)
-
Solution must provide 6 input entry fields to capture the following:
 
orderID ---[The cart these items belong to.] null
Example value:
example value
 
customerID ---[Internal UUID for customer] UUID
Example value:
)76uuyt&*6i
 
Unit Price ---[ Populated from the part selected] CURRENCY
Example value:
23.89
 
Quantity ---[Order quantity] INTEGER
Example value:
7
 
Shipping Address ---[Text from customer record.] STRING
Example value:
234 Kansas Drive, Kansas
 
Product ID ---[Non internal Prodct ID from catalog] STRING
Example value:
&67t%455uT6%

 
Specification: OE12 - Full Sales Order (pu) PERSIST
This Implementation:
-

Retain the Sales Order submitted by the Customer. A Create for the Full Sales Order Aggregate.
Specification:
Method: Create aggregate Validate and persist the Sales Order including Order Items.

Model Note: This represents an acceptance by the customer of the offer by the Product organization. A contract is created.
As such, its information is Financial, Personal, and an organizatinal Record.
From the Comitted Sales Order OE11.
The aggregate record is presented for persistence because the Customer has submitted the Order.
Some feedback is needed to confirm the order. (not currently shown)


Implementation Note: An aggregate to persist the order.

UI Note: No UI

As a Sales Manager I want to determine and provide: Full Sales Order (pu) so that subsequent decisions can be made.
-
Solution must present values from the following Assertions to support the decision:
  OE11 ---Submitted Order
    null (null)
    Connection Note:     This is across domains. It must ensure valid data.
-
  orderID      The cart these items belong to.
(             sample value:      example value)
  customerID      Internal UUID for customer
(             sample value:       )76uuyt&*6i)
  Unit Price       Populated from the part selected
(             sample value:       23.89)
  Quantity      Order quantity
(             sample value:       7)
  Shipping Address      Text from customer record.
(             sample value:       234 Kansas Drive, Kansas)
  Product ID      Non internal Prodct ID from catalog
(             sample value:       &67t%455uT6%)
-
Solution must calculate 3 output values for the following:
 
CustomerID ---[Internal UUID for customer Validation: Must be an existing id from Customer Entity] null
Example value:
)76uuyt&*6i
 
ShippingAddress ---[Text from customer record. Validation: Must be deliverable] STRING
Example value:
432 Kansas Drive, Kansas City, Kansas
 
OrderId ---[The customer order these items belong to. Validation: Must be a an existing OrderID for all but create.] STRING
Example value:
(77U77FFdeetS7768(7

 
Specification: OE18r - Available Parts List (pr) RETRIEVAL
This Implementation:
-

Retrieve the set of Parts that satisfy filter criteria, and the details for each
Specification:
Method: Post GetAvailablePartsForFilter Select all parts that match any of the filter items.

Model Note: Although automatic, the Sales Manager is responsible for maintining the catalog and this assertion that filters it.
Warehouse is not included in IMP1.
Assumption that this is a Part entity, described by the attribute of the assertion.
This can be simply tested using PostMan with a filter. The filter is provided in the body of the HTTP request.
This is used by Planned Order using a PULL connection.
The AM identifies a separate connection for the request but this can be implemented as a simple retrieve.



Implementation Note: This should be implemented in the Parts Entity.
It provides a retrieve method, GetAvailablePartsForFilter, to support the client.
The method should be exposed in the Parts Service and will be used in the Client to show the parts that meet the filter search criteria.
- Since this is used by UI the error trapping from the failed response must indicate a reason and re-try suggestions.

In this implementation this uses a view built on the partscategory table to impelement.

UI Note: None: Auto

As a Catalog Manager I want to determine and provide: Available Parts List (pr) so that subsequent decisions can be made.
-
Solution must present values from the following Assertions to support the decision:
  OE19 ---Parts Filter
    IMPL1 (null)
    Connection Note:     null
-
  CategoryName      Identity for which catefory this shopper has identified a search item
(             sample value:      VehicleType)
  SelectedCategoryItem      Value from enumeration of Items for a category
(             sample value:       SUV)
  OE06 ---Part (pr)
    IMPL1 (PULL)
    Connection Note:     An async retrieve that supplies an array of parts and is returned their details.
-
  productid      Internal UUID for persistent integrity
(             sample value:      43099&99aj)
  categoryId      Category for filtering. Vallidation: Must be listed in the Category Entity
(             sample value:       3099u75i3)
  Part Description(description)      Semi structured narrative of use of part and installation details.
(             sample value:      A wing mirror that can be fitted to any vehicle.)
  unitPrice      Price in CAD. Validation: Must be dollar amount. Validation: Cannot be set to zero.
(             sample value:       12.99)
  SKU      Stock Keeping Unit. Identifier, unique within this organization. Validation: Must be unique. Integer ascending by datetime.
(             sample value:      3387 )
  Name      Short identifying name to support search and match to physical product. Validation: Unique within Products.
(             sample value:       )
  OE16 ---Warehouse Inventory (pr)
    null (null)
    Connection Note:     null
--no type for this input assertion --
-
Solution must calculate 5 output values for the following:
 
PartID ---[Interchangable ID] STRING
Example value:
PPP334
 
UnitPrice ---[Price as of start of Cart] STRING
Example value:
$45.00
 
ShortDescription ---[Short Description by PP] STRING
Example value:
Brake Pad for Truck
 
PartUUID ---[EntityID] STRING
Example value:
part1
 
PartName ---[-- New Desc -- ] STRING
Example value:
BrakeMaster

 
Specification: OE19 - Parts Filter DECISION
This Implementation:
-

A UI Request to find a set of Parts that make up a Filter. Implemented in the UI.
Specification:
List the shopper, the category, and a category item to be included in a search.

Model Note: See the categories Entity for sturcture of possible categories and thier values.This Entity retains the state of the shoppers filter.They adjust the filter ie their set of categories and values until they are ready to ask for the list of available parts. Example: Choose one or more manufacturers from this list (Tesla, Toyota,Ferrari,BMW).
Choose Vehicle Type from this list (Automobile, MotorCycle, Scooter, Truck, Bus, Van). The input includes information about the categories and their items. (this is not required for the initial demonstration.

Implementation Note: Implemented by a list of Categories and Values.
This is presented and changed using a multiselect from all categories and values.


UI Note: The UI presents a multiselect of all the possible filter values, with an indicator showing those currently selected. The current set of the selected category values is emitted to query the parts and return a filtered parts display.

As a Customer(Sales) I want to determine and provide: Parts Filter so that subsequent decisions can be made.
-
Solution must present values from the following Assertions to support the decision:
  OE29 ---Parts Category Items (pr)
    IMPL1 (PULL)
    Connection Note:     NV_GET with Categories Filter
-
  General Comments      
(             sample value:      This Frame is included here as a composite. When a part is characterized this way (F150) the part fits an F150.)
  Category Name      Name of one of the ways Parts are characterized.
(             sample value:       Vehicle Type)
  Category Description      Details on how this categorization is determined.
(             sample value:      Characeristics like truck bed, number of doors, 2 or 4 wheel, weight)
  Category Item Name      A short identifier for the category item
(             sample value:      Truck)
  Category Item Description      -- New Desc --
(             sample value:      Part fits any of the F150 line. )
  Category Item Description      Assistance in deciding if the part fits the individual item choice.
(             sample value:       Has a truck bed, wide wheelbase and low gearing.)
-
Solution must provide 2 input entry fields to capture the following:
 
CategoryName ---[Identity for which catefory this shopper has identified a search item] STRING
Example value:
VehicleType
 
SelectedCategoryItem ---[Value from enumeration of Items for a category] STRING
Example value:
SUV

 
Specification: OE29 - Parts Category Items (pr) RETRIEVAL
This Implementation:
-

Retrieve all the Category and Category Items to support the Planned Order UI
Specification:
Mrthod: GET GetAllCategoryItems - select all rows in the CategoryItem table.

Model Note: This is used by the Client OE19 Parts Filter to provide choices to search the parts catlog for parts that (for example) are just for Mercedes Trucks.
This is the CategoryItems Entity decribed by the attributes of this assertion.
This can be simply unit tested using PostMan with a filter. The filter is provided in the body of the HTTP request.
This is used by Planned Order in the Client using a PULL connection.

Implementation Note: Implemented by Category Item Entity.
It provides a retrieve method, GetAllCategoryItems (with no params), to support the client.
- Since this is used by UI ,the error trapping from the failed response must indicate a reason and re-try suggestions.

UI Note: None: Automatic

As a Catalog Manager I want to determine and provide: Parts Category Items (pr) so that subsequent decisions can be made.
-
Solution must present values from the following Assertions to support the decision:
  OE28 ---Category (pr)
    null (null)
    Connection Note:     OE29
--no type for this input assertion --
-
Solution must calculate 6 output values for the following:
 
General Comments ---[ ] null
Example value:
This Frame is included here as a composite. When a part is characterized this way (F150) the part fits an F150.
 
Category Name ---[Name of one of the ways Parts are characterized.] STRING
Example value:
Vehicle Type
 
Category Description ---[Details on how this categorization is determined.] STRING
Example value:
Characeristics like truck bed, number of doors, 2 or 4 wheel, weight
 
Category Item Name ---[A short identifier for the category item] STRING
Example value:
Truck
 
Category Item Description ---[-- New Desc -- ] STRING
Example value:
Part fits any of the F150 line.
 
Category Item Description ---[Assistance in deciding if the part fits the individual item choice.] STRING
Example value:
Has a truck bed, wide wheelbase and low gearing.

 
Specification: BR02 - Order Total Costs CALCULATION
This Implementation:
-

A result of the application of the business rule that calculates taxes, shipping, and totals for an order and its items.
Specification:
Tax is 5% of the total. Shipping(is taxed) is 10% of the total, or 8% for orders over $1000.

Model Note: This business rule is the responsibility of the Sales Manger.
This is currently specified by text. but when implemented a function would automatically calculate the values.


This can be a separate bindable component?
Is this a Value Item?
This is definitely a business rule. But where does this 'reside'? Is it passed to the FE to execute or does each time the items change does the FE ask the aggregate for values?
A CHALLENGE QUESTION FOR IMPLEMENTATION DESIGN

Implementation Note: This business rule serves the UI (as modeled). It is calculated and displayed in the UI but is part of the Order, and would serve as an invariant in th order too.

The order items and quantities are required to calculate this.
Who Implements this?
Perhaps the js function is passed to the FE/Client to be used. IE as part of the build.
Code-wise this module is in both the Client and Server.
First, how to implement in FE?
This should be a function in order that takes the orderItems and populates the teotal fields. We know that order is an agregate. We need to define the java record
Types does this. How does the no valid data get into the Order aggregate.
I could write text, leet, js to be placed into the BC ie BinComp. BinComp has to have
get etc defined.
Lets do this in node. using CoP. First describe orderAggregate as a compex type in AM. Then generate the tables. (I have done this somewhere). Then create the crud methods as endpoints All this should/could be generated

BR02 and Orde ent are combined.
When I am done (acceptatnce) I will have an order entry aggregate that has some validations, an internal BRule. And a 'service' that offers get, update,delete,execute!
Which I can use with PMan to add records etc.
It can then be added as a service that OrdEnt uses to capture the order.
This looks like two weeks work.

UI Note:

As a Sales Manager I want to determine and provide: Order Total Costs so that subsequent decisions can be made.
-
Solution must present values from the following Assertions to support the decision:
  OE07 ---Planned Order
    null (null)
    Connection Note:     null
-
  Product ID       Populated from the part selected. Validation: Must be in the Product list
(             sample value:       PPP23)
  Quantity       Stated by the shopper. Validation: Orders over 100 of one part are not allowed.
(             sample value:      6 )
  Price       Populated from the part selected. Validation: must be the price in the Product Catalog The unit price of the part when added to cart.
(             sample value:       $41.89)
  orderId      The cart these items belong to. Validation: auto generated on creation.
(             sample value:      (*98&88YT)
  customerId      Internal UUID for customer. Validation: auto generated on creation.
(             sample value:       (8778J7&*)
  Context_UserToken       A token that controls access to the cubicle and the messages it manages
(             sample value:       33098&9775)
-
Solution must calculate 5 output values for the following:
 
Total Ordered Items ---[Sum of quantity * unit price] CURRENCY
Example value:
$5234
 
Shipping ---[10% (if total is > $1000 - 8%)] STRING
Example value:
$320
 
Total With Shipping ---[-- New Desc -- ] STRING
Example value:
$5789
 
Tax ---[5%] STRING
Example value:
$289
 
Total Payable ---[Items + Shipping + Tax] STRING
Example value:
$5976



JSON Specs

The following is the JSON object used to create the assertion list above. It is delivered as a Version 1 of the machine readable specs and is seen as evolving as NuVisum creates the proofing application to determine needed adjustmetns. (Your ide should indent this correctly)

{
  "Introduction": "This is the specification in a JSON format",
  "Assertions": [
    {
      "BaseAssertion": {
        "ActivityType": "RETRIEVAL",
        "Description": "Retrieve Customer details for a given Customer ID. Implemented in Customer Entity.  Initiated by the Planned Order UI.",
        "Specification": "Method:\nGET  GetCustomerDetailsForCustomerID\nReturn a single record for a Customer",
        "DBID": "13230",
        "SpecID": "OE04",
        "Name": "Customer",
        "Authority": "Sales Manager",
        "ImplementationNote": "For the NV environment this is seen as an Entity that shows all Customers. And an SQL query for a CustomerID.\n",
        "ModelNote": "This retrieval is used to add the customer address when they make an order.\nThis can be simply tested using PostMan with a customerID. ",
        "UINote": "None Automatic",
        "Attributes": [
          {
            "Name": "First Name",
            "Type": null,
            "Description": "Customer First name",
            "ExampleValue": "Mo\n"
          },
          {
            "Name": "Customer Number",
            "Type": "STRING",
            "Description": "Unique identity for external identification",
            "ExampleValue": " PPC342"
          },
          {
            "Name": "Last Name",
            "Type": "STRING",
            "Description": "Customer last name",
            "ExampleValue": " Jones"
          },
          {
            "Name": "Full Address",
            "Type": "STRING",
            "Description": "Delivery address to support courier delivery.\nValidation:  text to identify location.\n",
            "ExampleValue": " 1234 Any St., Ohioville, PA"
          }
        ]
      }
    },
    {
      "BaseAssertion": {
        "ActivityType": "RETRIEVAL",
        "Description": "Retrieve details about the Part to support the Planned Order UI.  -- An Entity retrieval.  -- Initiated from Parts Filter UI",
        "Specification": "Method:\nPOST: GetDetailsForPartIDs-\nReturn all parts details for the PartID",
        "DBID": "13232",
        "SpecID": "OE06",
        "Name": "Part (pr)",
        "Authority": "Catalog Manager",
        "ImplementationNote": "For the NV environment this is seen as an Entity that shows all products. And an assembled SQL query.",
        "ModelNote": " Although automatic, the Catalog Manager is responsible for maintining the catalog and this assertion that deliivers it. \nThis is a second retrieval from the Parts Entity (similar to OE18r)\nThis retrieves by PartIDs.\nThis can be simply tested using PostMan with a filter. The filter is provided in the body of the HTTP request.\nThis is used by Planned Order using a PULL connection.  ",
        "UINote": "None: Automatic.",
        "Attributes": [
          {
            "Name": "productid",
            "Type": "UUID",
            "Description": "Internal UUID for persistent integrity",
            "ExampleValue": "43099&99aj"
          },
          {
            "Name": "categoryId",
            "Type": "STRING",
            "Description": "Category for filtering.\nVallidation: Must be listed in the Category  Entity ",
            "ExampleValue": " 3099u75i3"
          },
          {
            "Name": "Part Description(description)",
            "Type": "STRING",
            "Description": "Semi structured narrative of use of part and installation details.",
            "ExampleValue": "A wing mirror that can be fitted to any vehicle."
          },
          {
            "Name": "unitPrice",
            "Type": "CURRENCY",
            "Description": "Price in CAD.\nValidation:  Must be dollar amount.\nValidation: Cannot be set to zero.",
            "ExampleValue": " 12.99"
          },
          {
            "Name": "SKU",
            "Type": "STRING",
            "Description": "Stock Keeping Unit. Identifier, unique within this organization.\nValidation:  Must be unique. Integer ascending by datetime.",
            "ExampleValue": "3387 "
          },
          {
            "Name": "Name",
            "Type": "STRING",
            "Description": "Short identifying name to support search and match to physical product.\nValidation:  Unique within Products.\n",
            "ExampleValue": " "
          }
        ]
      }
    },
    {
      "BaseAssertion": {
        "ActivityType": "CONFIGURATION",
        "Description": "A collection of Planned Part Items for a Customer. Implemented in the UI and used to determine total costs.\n",
        "Specification": "The Customer must inspect the Product Catlog in order to determine Product capabilities, fit, and prices. For this Simple example we assume they have a way of inspecting available parts subsetted by category items. ---Customer must decide to add an order item to the Planned Order (they have not comitted to buy yet). They can submit this information to the business rule that automatically determines total costs and shipping. ",
        "DBID": "13233",
        "SpecID": "OE07",
        "Name": "Planned Order",
        "Authority": "Customer(Sales)",
        "ImplementationNote": "Probably part of the HTML...",
        "ModelNote": "This is a list of Products  and quantities that a customer intends to order.\n\nFor Assertum this is a complex type and needs some additional finishing of the types concept.\n\nTBD: The frame needs compex types.\n",
        "UINote": "Provide the ability to filter the full product catalog by category.",
        "Attributes": [
          {
            "Name": "Product ID",
            "Type": "STRING",
            "Description": " Populated from the part selected.\nValidation: Must be in the Product list",
            "ExampleValue": " PPP23"
          },
          {
            "Name": "Quantity",
            "Type": "STRING",
            "Description": " Stated by the shopper.\nValidation: Orders over 100 of one part are not allowed.",
            "ExampleValue": "6 "
          },
          {
            "Name": "Price",
            "Type": "STRING",
            "Description": " Populated from the part selected. \nValidation: must be the price in the Product Catalog\nThe unit price of the part when added to cart.",
            "ExampleValue": " $41.89"
          },
          {
            "Name": "orderId",
            "Type": "STRING",
            "Description": "The cart these items belong to. \nValidation: auto generated on creation.",
            "ExampleValue": "(*98&88YT"
          },
          {
            "Name": "customerId",
            "Type": "UUID",
            "Description": "Internal UUID for customer.\nValidation: auto generated on creation.",
            "ExampleValue": " (8778J7&*"
          },
          {
            "Name": "Context_UserToken",
            "Type": "STRING",
            "Description": " A token that controls access to the cubicle and the messages it manages",
            "ExampleValue": " 33098&9775"
          }
        ]
      }
    },
    {
      "BaseAssertion": {
        "ActivityType": "INTENT",
        "Description": "Submit the decision to purchase an Order and its Items.  ",
        "Specification": "Populate the Shipping details from the Customer Record and and the current order from Planned Order.\nThe customer is presented with the full details of the order and committs with an acceptance (contractural).",
        "DBID": "13245",
        "SpecID": "OE11",
        "Name": "Submitted Order",
        "Authority": "Customer(Sales)",
        "ImplementationNote": "",
        "ModelNote": "An interesting assertion. Might be only an emit.\n\nThis is the sales order as it is persisted. It is necessary that the order have automatic business rules applied before it is persisted. This is a business decision. The alternative is that the BR is applied on retrieval. An interesting design point.And this is interesting because it might be modeled with a recursive business rule but the assertion should not emit unless fully populated.If this is customer it is only items and not populated??Once comitted by customer it is persisted. (when received by pu)This is manual because the customer has to inspect it to make the comittment (contractural acceptance).",
        "UINote": "",
        "Attributes": [
          {
            "Name": "orderID",
            "Type": null,
            "Description": "The cart these items belong to.",
            "ExampleValue": "example value"
          },
          {
            "Name": "customerID",
            "Type": "UUID",
            "Description": "Internal UUID for customer",
            "ExampleValue": " )76uuyt&*6i"
          },
          {
            "Name": "Unit Price",
            "Type": "CURRENCY",
            "Description": " Populated from the part selected",
            "ExampleValue": " 23.89"
          },
          {
            "Name": "Quantity",
            "Type": "INTEGER",
            "Description": "Order quantity",
            "ExampleValue": " 7"
          },
          {
            "Name": "Shipping Address",
            "Type": "STRING",
            "Description": "Text from customer record.",
            "ExampleValue": " 234 Kansas Drive, Kansas"
          },
          {
            "Name": "Product ID",
            "Type": "STRING",
            "Description": "Non internal Prodct ID from catalog",
            "ExampleValue": " &67t%455uT6%"
          }
        ]
      }
    },
    {
      "BaseAssertion": {
        "ActivityType": "PERSIST",
        "Description": "Retain the Sales Order submitted by the Customer. A Create for the Full Sales Order Aggregate.",
        "Specification": "\nMethod: Create aggregate\n\n\nValidate and persist the Sales Order including Order Items.",
        "DBID": "13246",
        "SpecID": "OE12",
        "Name": "Full Sales Order (pu)",
        "Authority": "Sales Manager",
        "ImplementationNote": "An aggregate to persist the order.",
        "ModelNote": "This represents an acceptance by the customer of the offer by the Product organization. A contract is created.\nAs such, its information is Financial, Personal, and an organizatinal Record.\nFrom the Comitted Sales Order OE11.\nThe aggregate record is presented for persistence because the Customer has submitted the Order.\nSome feedback is needed to confirm the order. (not currently shown)\n",
        "UINote": "No UI",
        "Attributes": [
          {
            "Name": "CustomerID",
            "Type": null,
            "Description": "Internal UUID for customer\nValidation: Must be an existing id from Customer Entity",
            "ExampleValue": " )76uuyt&*6i"
          },
          {
            "Name": "ShippingAddress",
            "Type": "STRING",
            "Description": "Text from customer record.\nValidation: Must be deliverable",
            "ExampleValue": "  432 Kansas Drive, Kansas City, Kansas"
          },
          {
            "Name": "OrderId",
            "Type": "STRING",
            "Description": "The customer order these items belong to.\nValidation: Must be a an existing OrderID for all but create.",
            "ExampleValue": " (77U77FFdeetS7768(7"
          }
        ]
      }
    },
    {
      "BaseAssertion": {
        "ActivityType": "RETRIEVAL",
        "Description": "Retrieve the set of Parts that satisfy filter criteria, and the details for each\n",
        "Specification": "Method: \nPost GetAvailablePartsForFilter\nSelect all parts that match any of the filter items.",
        "DBID": "13254",
        "SpecID": "OE18r",
        "Name": "Available Parts List (pr)",
        "Authority": "Catalog Manager",
        "ImplementationNote": "This should be implemented in the Parts Entity.\nIt provides a retrieve method, GetAvailablePartsForFilter, to support the client.\nThe method should be exposed in the Parts Service and will be used in the Client to show the parts that meet the filter search criteria.\n- Since this is used by UI the error trapping from the failed response must indicate a reason and re-try suggestions.\n\nIn this implementation this uses a view built on the partscategory table to impelement.",
        "ModelNote": " Although automatic, the Sales Manager is responsible for maintining the catalog and this assertion that filters it. \nWarehouse is not included in IMP1.\nAssumption that this is a Part entity, described by the attribute of the assertion.\nThis can be simply tested using PostMan with a filter. The filter is provided in the body of the HTTP request.\nThis is used by Planned Order using a PULL connection.  \nThe AM identifies a separate connection for the request but this can be implemented as a simple retrieve.\n\n",
        "UINote": "None: Auto\n\n",
        "Attributes": [
          {
            "Name": "PartID",
            "Type": "STRING",
            "Description": "Interchangable ID",
            "ExampleValue": " PPP334"
          },
          {
            "Name": "UnitPrice",
            "Type": "STRING",
            "Description": "Price as of start of Cart",
            "ExampleValue": " $45.00"
          },
          {
            "Name": "ShortDescription",
            "Type": "STRING",
            "Description": "Short Description by PP",
            "ExampleValue": " Brake Pad for Truck"
          },
          {
            "Name": "PartUUID",
            "Type": "STRING",
            "Description": "EntityID",
            "ExampleValue": " part1"
          },
          {
            "Name": "PartName",
            "Type": "STRING",
            "Description": "-- New Desc -- ",
            "ExampleValue": " BrakeMaster"
          }
        ]
      }
    },
    {
      "BaseAssertion": {
        "ActivityType": "DECISION",
        "Description": "A UI Request to find a set of Parts that make up a Filter. Implemented in the UI.\n",
        "Specification": "List the shopper, the category, and a category item to be included in a search.",
        "DBID": "13255",
        "SpecID": "OE19",
        "Name": "Parts Filter",
        "Authority": "Customer(Sales)",
        "ImplementationNote": "Implemented by a list of Categories and Values.\nThis is presented and changed using a multiselect from all categories and values.\n",
        "ModelNote": "See the categories Entity for sturcture of possible categories and thier values.This Entity retains the state of the shoppers filter.They adjust the filter ie their set of categories and values until they are ready to ask for  the list of available parts. Example:  Choose one or more manufacturers from this list (Tesla, Toyota,Ferrari,BMW).\nChoose Vehicle Type from this list (Automobile, MotorCycle, Scooter, Truck, Bus, Van). The input includes information about the categories and their items. (this is not required for the initial demonstration.",
        "UINote": "The UI presents a multiselect of all the possible filter values, with an indicator showing those currently selected.\nThe current set of the selected category values is emitted to query the parts and return a filtered parts display.\n\n",
        "Attributes": [
          {
            "Name": "CategoryName",
            "Type": "STRING",
            "Description": "Identity for which catefory this shopper has identified a search item",
            "ExampleValue": "VehicleType"
          },
          {
            "Name": "SelectedCategoryItem",
            "Type": "STRING",
            "Description": "Value from enumeration of Items for a category",
            "ExampleValue": " SUV"
          }
        ]
      }
    },
    {
      "BaseAssertion": {
        "ActivityType": "RETRIEVAL",
        "Description": "Retrieve all the Category and Category Items to support the Planned Order UI",
        "Specification": "Mrthod:\nGET  GetAllCategoryItems\n- select all rows in the CategoryItem table.  ",
        "DBID": "13273",
        "SpecID": "OE29",
        "Name": "Parts Category Items (pr)",
        "Authority": "Catalog Manager",
        "ImplementationNote": "Implemented by Category Item Entity.\nIt provides a retrieve method, GetAllCategoryItems (with no params), to support the client.\n- Since this is used by UI ,the error trapping from the failed response must indicate a reason and re-try suggestions.",
        "ModelNote": "This is used by the Client OE19 Parts Filter to provide choices to search the parts catlog for parts that (for example) are just for Mercedes Trucks.\nThis is the CategoryItems Entity decribed by the attributes of this assertion.\nThis can be simply unit tested using PostMan with a filter. The filter is provided in the body of the HTTP request.\nThis is used by Planned Order in the Client using a PULL connection.",
        "UINote": "None: Automatic",
        "Attributes": [
          {
            "Name": " General Comments",
            "Type": null,
            "Description": " ",
            "ExampleValue": "This Frame is included here as a composite. When a part is characterized this way (F150) the part fits an F150."
          },
          {
            "Name": "Category Name",
            "Type": "STRING",
            "Description": "Name of one of the ways Parts are characterized.",
            "ExampleValue": " Vehicle Type"
          },
          {
            "Name": "Category Description",
            "Type": "STRING",
            "Description": "Details on how this categorization is determined.",
            "ExampleValue": "Characeristics like  truck bed, number of doors, 2 or 4 wheel, weight"
          },
          {
            "Name": "Category Item Name",
            "Type": "STRING",
            "Description": "A short identifier for the category item",
            "ExampleValue": "Truck"
          },
          {
            "Name": "Category Item Description",
            "Type": "STRING",
            "Description": "-- New Desc -- ",
            "ExampleValue": "Part fits any of the F150 line.  "
          },
          {
            "Name": "Category Item Description",
            "Type": "STRING",
            "Description": "Assistance in deciding if the part fits the individual item choice.",
            "ExampleValue": " Has a truck bed, wide wheelbase and low gearing."
          }
        ]
      }
    },
    {
      "BaseAssertion": {
        "ActivityType": "CALCULATION",
        "Description": "A result of the application of the business rule that calculates taxes, shipping, and totals for an order and its items.",
        "Specification": "Tax is 5% of the total. Shipping(is taxed)  is 10% of the total, or 8% for orders over $1000.",
        "DBID": "13287",
        "SpecID": "BR02",
        "Name": "Order Total Costs",
        "Authority": "Sales Manager",
        "ImplementationNote": "This business rule serves the UI (as modeled). It is calculated and displayed in the UI but is part of the Order, and would serve as an invariant in th order too.\n\n The order items and quantities are required to calculate this.\nWho Implements this?\nPerhaps the js function is passed to the FE/Client to be used. IE as part of the build.\nCode-wise this module is in both the Client and Server.\nFirst, how to implement in FE?\nThis should be a function  in order that takes the orderItems and populates the teotal fields. We know that order is an agregate. We need to define the java record\nTypes does this. How does the no valid data get into the Order aggregate.\nI could write text, leet, js to be placed into the BC ie BinComp. BinComp has to have \nget etc defined.\nLets do this in node. using CoP. First describe orderAggregate as a compex type in AM. Then generate the tables. (I have done this somewhere). Then create the crud methods as endpoints All this should/could be generated\n\nBR02 and Orde ent are combined.\nWhen I am done (acceptatnce) I will have an order entry aggregate that has some validations, an internal BRule. And a 'service' that offers get, update,delete,execute!\nWhich I can use with PMan to add records etc.\nIt can then be added as a service that OrdEnt uses to capture the order.\nThis looks like two weeks work.",
        "ModelNote": "This business rule is the responsibility of the Sales Manger.\nThis is currently specified by text. but when implemented a function would automatically calculate the values.\n\n\nThis can be a separate bindable component?\nIs this a Value Item?\nThis is definitely a business rule. But where does this 'reside'? Is it passed to the FE to execute or does each time the items change does the FE ask the aggregate for values?\nA CHALLENGE QUESTION FOR IMPLEMENTATION DESIGN ",
        "UINote": "",
        "Attributes": [
          {
            "Name": "Total Ordered Items",
            "Type": "CURRENCY",
            "Description": "Sum of quantity * unit price",
            "ExampleValue": "$5234"
          },
          {
            "Name": "Shipping",
            "Type": "STRING",
            "Description": "10% (if total is > $1000 - 8%)",
            "ExampleValue": " $320"
          },
          {
            "Name": "Total With Shipping",
            "Type": "STRING",
            "Description": "-- New Desc -- ",
            "ExampleValue": " $5789"
          },
          {
            "Name": "Tax",
            "Type": "STRING",
            "Description": "5%",
            "ExampleValue": " $289"
          },
          {
            "Name": "Total Payable",
            "Type": "STRING",
            "Description": "Items + Shipping + Tax",
            "ExampleValue": " $5976"
          }
        ]
      }
    }
  ]
}