Preferences have a language

Problem: Preferences and custom configurations for customers/clients/partners are scattered among many different data stores, such as in database tables and config files.

Pattern: A declarative Domain Specific Language (DSL) is developed for marking up preferences and configuration. Preferences are stored in one file per client with a "profile resolver" to help applications discover the file and read it.

Example: 

<ClientProfile xmlns="http://schemas.mycompany.com/ClientProfile">
    <ClientInfo>
        <Name>Bob's Discount Outlet</Name>
        <ClientCode>ABC123</ClientCode>
    </ClientInfo>

    <BillingTerms Type="Invoice">
        <CreditLimit>$10,000</CreditLimit>
        <OverlimitAlert>accounting@mycompany.com</OverlimitAlert>
        <InvoiceTo ContactType="accounts-payable"/>
    </BillingTerms>

    <Contact Type="accounts-payable">
        <Name>Bob Jones</Name>
        <Address1>300 Corporate Park</Address1>
        <City>Fnord</City>
        <State>NY</City>
        <PostalCode>12345</PostalCode>
    </Contact>

    <FulfillmentPolicy>
        <ShippingAccount Carrier="UPS" CarrierAccount="1234ABC" BillingType="ThirdParty">
            <BillingAddress>
                <!-- billing address goes here -->
            </BillingAddress>
        </ShippingAccount>

        <PackingSlip Style="CUSTOMLOGO">
            <Logo Image="boboutlet.png"/>
            <TradeName>Bob's Discount Outlet</TradeName>
            <ReturnAddress>
                <!-- return address goes here -->
            </ReturnAddress>
        </PackingSlip>
    </FulfillmentPolicy>
</ClientProfile>

Discussion: The above is in XML, but could as easily be JSON or YAML or some other underlying syntax. Applications that need discrete parts of the client profile would contact a "ProfileResolver" service that, given a name or ID, returns the body of the profile for parsing by the application. Each application should only need to understand the parts that are relevant for it, so the accounting software ignores everything but <BillingTerms>, while the Orders-2-Cash software only interprets the contents of <FulfillmentPolicy>. One of the reasons why XML is a good choice is because parsers are ubiquitous and have APIs that make it simple to search the DOM for nodes of interest.

 Even the definition of an "application" that reads the profile is flexible. For the sake of documentation, an XSLT stylesheet can be developed that converts profiles into web, PDF or printed summaries to any depth of detail needed. As the profile is changed, the documentation can be updated automatically.
Comments