(Based on issues that came up under SharingDataIsImportant)

An "application" is generally partitioned by role or function. However, the world wants better integration of everything. The partitions used in practice tend to be UsefulLie''''''s I have come to conclude. For example, you can buy sales-force automation software. The problem though is integrating it with your product lines. If you sell complex products, then the off-the-shelf sales software probably cannot handle it well without modification or without accepting compromises. If the software does not "understand" your products, then it is of limited use. Thus, the boundary between "sales" and "products" is fuzzy.


-------

A UseNet snippet on this topic:

SQL in code is not evil [although better relational alternatives should be persued].

''Agreed.  SQL is not evil.  But combining it with business rules is inadvisable.''

In a good design, most of the code should be business rules. If it is
GUI management, for example, then you are not using the appropriate
libraries/tools/languages. You are not coding to the domain but wasting
code on technlogy issues or the like rather than spending code on
solving the problem at hand.

''A huge amount of effort goes into mapping business data into presentation formats.  This mapping is not a business rule, per se; but is still complicated and important code that needs to be written. It should be separate from the business rules. ''

The dividing line between such is rather blurry in practice.

For example, we may start out with:

  if threshold greaterThan 100 then display_as_red
  else if threshold greaterThan 50 then display_as_yellow
  else display_as_white

This is as much a "business rule" as any.  But it is also a display
issue.

Now suppose that different managers want different threashold colors
and ranges and want to self-tweak them. At such a point we may
"meta-tize" the logic by having a table such as:

  table: thresholdColors
  ----------------------
  mgrRef  (manager reference ID)
  amount  (upper limit range, double or float)
  color      (web color format rrggbb)

This is more or less the same thing as before, but represented
declaratively instead.

Back to the display issue. If this was recorded in a log instead of
just displayed, would that change its classification in your mind? In
otherwords, the dichotomy between "display" and "process" is flimsey in
the biz world because whether something is display data or "kept" data
(processing) is only a small difference. There have been many times
where someone will ask, "Can we keep these report results every week
instead of just display them so that we can study trends and changes?"

One may suggest that one can simply use the raw data instead to
regenerate as needed, but what if they want to see the threasholds as
set in the past rather than see past data with current threadholds?
(The peskiest managers will want both views.) This is fairly common
with rate information: they may want to see old data with the old
rates, not the current rates. Either we store historical rates, or we
just store a snap-shot of the calculations at a given point.


''Similarly, there is often a large amount of effort that goes into mapping the business data into a persistent repository (i.e. a database) that is accessible and usable by many different applications.  Once again this mapping is not a business rule, per se; but is still complicated and important code that needs to be written. It should be separate from the business rules.'' 

I view a RDBMS as a powerful processing tool, not JUST "storage". One
can often convert a lot of code into a declarative format, somewhat
like above. In fact, one can convert *most* of the code into such if
you really wanted to. However, the practicality of the extreme
declarative approach is questionable (at least with today's tools).

In summary, I don't think clear lines can be drawn. (Unless perhaps
your methodology dictates up-front what to declaratize and what not
to.)

--top