Viking direct marketing system

OOPSLA '00 DesignFest® problem, October 15, 2000

Design team:

  Bill Hofmann - moderator
  Dennis Mancl - recorder
  Aaron Mohrman
  Mark Steffel
  Igor Vinnychuk
  Michael Welch
 

From the problem statement:

The Viking is a system that maintains information about customers and can send them letters tailored with
important, relevant, and time-critical information. The Viking is the core of a direct marketing system: it
will directly interact with users to configure the campaigns and will work with other system components
to accomplish the mailing itself.


Class diagram for Viking


The central classes in this system are:

Risks (possible development problems and design evolution problems)

  1. Need to add new "Mailing address" subclass when a new "Mailing system" class is added to the system [user story 3]
  2. "Tracking string" may be an inadequate identifier (not unique, inaccessible on failure, etc.) [user story 8]
  3. Users need to have flexible "Customer selector" classes, but users might lack experience to write their own [user story 4]
  4. Developers may decide to go too far and create their own programming language for "Customer selector" [user story 4]
  5. Template Group objects will be complex to update [user story 6]

Sequence diagrams for selected user stories

In user story 1, the system must be able to generate a Letter (by expanding a Template correctly for a particular Customer).



In user story 3, the system must be able to mail Letters to a group of Customers.  The Mailing system must be flexible, so the mail can be sent by email or by "paper mail".



In user story 4, the group of Customers that will have letters generated for them must be selected by some kind of simple criterion.  The Customer selector will encapsulate the criterion.



In user story 8, the system must record information about Letters that have failed delivery.  In this design, the corresponding Delivery attempt object will hold that status information.



In user story 7, the system must handle Tag objects that can produce a list of values.  The values might be retrieved from a database, or they might be determined by following associations in the object model.  This scenario illustrates the scenario "find a list of companion products from all the Orders placed by the Customer".



In user story 6, the Template Group class is introduced to allow customized Letters to be sent to different kinds of Customers -- for example, a Template Group might contain Templates in different languages.  Each Template in a Template Group has a priority, so the Templates will be applied in priority order, and duplicate Customers will not be sent multiple Letters.






Last modified:  Oct. 21, 2000