title: Design pattern for handling many parameters and business rules
body: <p>I am working on a project that is responsible for creating a "job" which is composed of one or more "tasks" which are persisted to a database through a DAL. The job and task columns are composed of values that are set according to business rules.</p>
  
  <p>The class, as it exists now, is getting complicated and unwieldy because the business rules dictate that it needs access to many databases across our system to decide whether a job can be created and/or how it should be set up.</p>
  
  <p>To further complicate things it needs to be necessary to submit a list of jobs and it needs to be callable in a variety of ways (as a referenced assembly, via windows service, or via web service).</p>
  
  <p>Here are some examples of the things it does:</p>
  
  <ul>
  <li>Generate a job cost estimate</li>
  <li>Take in an account and/or user to which assign the job</li>
  <li>Emit an event for job submission progress tracking</li>
  <li>Merge in data from an outside, user-defined list (.csv, .xls, ect.)</li>
  <li>Copy files from a local drive to a network accessible drive (if necessary)</li>
  </ul>
  
  <p>My question is: What are the best practices or design patterns to make this as manageable and simple as possible?</p>