Precise.docx - Pg 1 Introduction and background for...

Pg 1
Introduction and background for Information Modeling/DDD
Stepping back from the immediate task of database design, it is helpful to appreciate that a model
starts and ends with a mental structure, in our head, using top level concepts that are innate and
are subclassed to fit the domain under consideration.
It also helps to know the human concepts that can be used to achieve precision in our models. (how can you
conceptually model if you don’t know what modeling concepts are available)?
I call these top level concepts (topcats)-- here are the main ones -- {State, Event, Action, Location, Path, Sound,
Image, Amount, Number, Manner, Time, Thing, , , } These and their subtypes are what we think with and therefore
what we model with.. (see the references -Jackendoff/Rucker).
If I can’t encompass the structure and intent of a model in my head, then I can’t develop, revise,
or improve it. This capability to make a model better is often expressed as being able to “wrap
my head around it”. Such a well recognized human characteristic brings me to my main point:
We work best by recognizing significant boundaries within an area, and then work to wrap our
head around each bounded context in turn, in order to manipilate it. These bounded areas are
the bounded contexts in the Domain Driven Design perspective .
**Note: the meaning of the word model is as complex as is the meaning of the word game and as difficult to pin
down. So, this means that models are not characterized by necessary and sufficient conditions (iff), but rather by
family-like resemblances. Our task, as developers, is to characterize and document these family resemblances
within an organizational domain of information modeling. ( see references L. Wittgenstein).
*As a bonus for learning this perspective, you will have a solid initial approach to thinking about
how to partition and then implement your own applications. “Data type structures are designed
separate from the Service Functions that operate on them”. (Other concepts such as
modularization are also crucial in software design and will be discussed on other papers).
Just to give some made up examples: Suppose the Service Functions access the Bounded
Contexts as follows:
Note that the parameters of the service functions are the data types of the bounded contexts!!
But the data types ARE the objects! What a beautiful simplification!
1.) Service-FunctionA1 through Service-FunctionA10 are targeted for the objects of bounded
context “1” .
e.g. made up examples: function(datatype1, datatype2, datatype3, . . .) → result of value
Suppose Service-FunctionsAn target the Bounded Context “1”, employee, department, . . objects
Service-FunctionA1( employee, department) → results in insurance status of employee
Service-FunctionA2( employee, department, companyPolicy) → results in number of dependents
of employee
2.) Suppose Service-FunctionB1 through Service-FunctionB5 are targeted to BC “2”.