14.2 First-Pass Design

I will start by trying to identify some possible fortresses . Because customers will be using browsers, I know that I will have at least one presentation fortress. Vendors will be coming into my system programmatically, so I know I will need a Web service fortress. I also know that I will have at least one business application fortress to process the requests . So far, I am up to three fortresses. But how many business application fortresses should I have? And what about treaty management and service fortresses?

Let me start by identifying the functionality that I think needs to be in the system someplace:

1. Customer gateway: sending catalog information, accepting browser requests, and preparing the order information

2. Vendor gateway: accepting SOAP requests from vendors

3. Vendor management: processing vendor requests and checking inventory

4. Order management: processing customer orders

5. Customer information: remembering billing, credit card, and other customer-specific information

6. Inventory information: tracking my store's inventory

7. Shipping: preparing an order to ship to the customer

8. Credit card processing: interfacing with the external credit card companies

9. Security: making sure the vendor request is coming from an authorized company

Having both a vendor gateway (that accepts the SOAP requests) and a vendor management fortress (that processes the vendor requests) may seem odd. But keep in mind that the Web service fortress provides a critical security buffer, and that buffer shouldn't contain any proprietary information.

For my first pass through the system, I will create a fortress for each of the major pieces of functionality that I have enumerated here. This is not unlike how I might approach an object-oriented design session. From this first pass I get the following fortresses:

1. CustomerGateway::Presentation Fortress

2. VendorGateway::Web Service Fortress

3. VendorInventoryCheck::Treaty Management Fortress

4. OrderManagement::Treaty Management Fortress

5. Customer::Business Application Fortress

6. Inventory::Business Application Fortress

7. Shipping::Business Application Fortress

8. CreditCardProcessing::Business Application Fortress

9. Security::Service Fortress

In addition to the fortresses, I will have two treaties : one that governs how the fortresses work together to process a customer order (which I'll call ProcessOrder), and one to process a vendor inventory check (which I'll call CheckInventory).

Let's get an overview of what form this enterprise system might take. Figure 14.1 shows a fortress “ally diagram (FAD) for my new enterprise.

Figure 14.1. Fortress “Ally Diagram

The FAD shows a lot of detail, so I'll step back a few paces and look at a couple of sequence “ally diagrams (SADs). Figure 14.2 shows the SAD for my system's ProcessOrder treaty, and Figure 14.3 shows the SAD for my system's CheckInventory treaty.

Figure 14.2. SAD for ProcessOrder

Figure 14.3. SAD for CheckInventory