Design, in and of itself, is a complex cognitive task bringing to bear a host of knowledge types and sources and a myriad of problem solving skills
[Dasgupta, 1991]. A number of researchers have shown that complexity is an essential property of design activities in general, due in part to the inevitably incomplete formulation of the problem, and in part to our inability to cope simultaneously with all of the constraints of a given problem (our bounded rationality [Simon, 1982]).
To help us, during the course of last year, the DDD community introduced new design patterns such as Domain Events, CQRS, Event Sourcing and Sagas. Albeit not new, the application’s of these patterns in DDD is nevertheless refreshing.
After reading a lot about these patterns I was able to understand each pattern individually within the scope of DDD. Yet when we get everything together, I always felt that a peace of the puzzle is missing, without which we may fall into a design “cliff” back into muddy waters with our designs.
In search for what was missing in my brain to fully understand these patterns I came up with just another formulation for domain modeling and design that you might appreciate. This is not the accepted DDD formulation, still it is about DDD.
This will the the first post, of my first attempt in explaining what I’ve learned in the latest in the DDD forum and intertwined my own perception of domain modeling and design.
Facts & Figures
I mostly build business software solutions in the Insurance context. So in my attempt to find the core artifacts of domain modeling I started observing what is required for domain experts to make them.
In turns out that my observable experience business decisions are made after considering facts and calculated figures in context. Decisions lead to other facts and figures and so on.
So why aren’t we using facts and figures as core archetypes in our designs?
To find the answer to these questions we need to establish a common undetstanding of the terms above
. I believe that this understanding all it is needed to make effective domain models across all sort of programming paradigms.
Decision: A determination arrived at after consideration.
Example: Buy my self an iPad in the online Apple Store
Consideration of what? Consideration of things that the business believes as facts. The outcome of this process is a set constraints over decisions.
Constraint: The state of being checked, restricted, or compelled to avoid or perform some action.
Example: If Nuno has no valid credit card he cannot buy an iPad in the online Apple Store.
So considering that fact that Nuno has no valid credit card, he cannot buy the iPad on the online Apple Store.
Fact: A thing done or performed. A provable concept. 
Example: Nuno bought an iPad in the online Apple Store.
Figure: A written or printed symbol representing something other than a letter, especially a number. Figures usually vary in precision. When a figure is provable, is often referred as a fact.
Example: Nuno bought 1 iPad in the online Apple Store.
In my next article I’ll expand a bit more about these concepts. Until then, and if you know about the DDD patterns enumerated above, consider that events are with we may call axioms …
