Tech Off Thread

3 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Architecture for Service Based Charges

Back to Forum: Tech Off
  • User profile image
    Shrage

     

    I‘m designing a software for companies that charge for services rather then products sold. Since service charges are more complex I need to design a solid framework that supports any type of service, I want to separate the charge system from the actual service being charged.

     

    I have some ideas and want to start a specific thread for this issue, is someone interest to work together to define this system, this will be helpfull for all taking a part or watching it?

  • User profile image
    Manip

    That is just insane .. With the above it could be a product with a budget of $100 or $10mill or more .. even microsoft wouldn't (hasn't) undertaken such a broad project..

  • User profile image
    Shrage

    Every framework can be a product of $100 or $10mill. Look at the CSLA framework for business objects at http://www.lhotka.net/ArticleIndex.aspx?area=CSLA%20.NET it's also very broad, we end up with Classes that every business developer will use, a developer can customize it, and also templates that uses the system in different ways.
     
    Once it's worked out well it can make a developers life a lot easier.

    For example here are some definitions for this system.
    1) a Service Charge object.
    2) any service object.
    3) a Transaction object

    -- A Service Charge object --
    1) Rate
    2) Per Unit (It is the responsibility of each specific service object to calculate its own qty. and pass it)
    3) When to charge
    4) Restriction (Global, Specific Customer, any other filter)

    -- A Service --
    Each service item, should implement a Service interface which the charge object uses to get Charge info about that Service, and a transaction object uses to get a Description string for the line item.

    -- A transaction object --
    Uses history information to combine information from a service and its charges, to create an invoice.

    Summery
    I think we can come up with an overall good system which will allow developers to specialize it for a specific situation very easily.

    What do you say?

     

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.