Table of contents generated with markdown-toc
No, I am not an expert on Domain-Driven Design (DDD), but I like to connect the dots, so I would like to cast DDD in the context of Philosophy; more specifically Bounded Contexts in context of Ontology, epistemology and research paradigm, where a ‘Bounded Context’ is a ‘Paradigm’, where a ‘Domain’ is a ‘Bounded Context’.
In the larger sense, I have worked on many projects in my career, and they are always lacking in the kind of understanding I crave. In the game of Chinese Whispers
Players form a line or circle, and the first player comes up with a message and whispers it to the ear of the second person in the line. The second player repeats the message to the third player, and so on. When the last player is reached, they announce the message they heard to the entire group. The first person then compares the original message with the final version. Although the objective is to pass around the message without it becoming garbled along the way, part of the enjoyment is that, regardless, this usually ends up happening. Errors typically accumulate in the retelling, so the statement announced by the last player differs significantly from that of the first player, usually with amusing or humorous effect. Reasons for changes include anxiousness or impatience, erroneous corrections, and the difficult-to-understand mechanism of whispering.
The game is often played by children as a party game or on the playground. It is often invoked as a metaphor for cumulative error, especially the inaccuracies as rumours or gossip spread, or, more generally, for the unreliability of typical human recollection.
Some more so, some less so… Indeed, a common problem of all collaborative efforts is establishing a shared understanding of what we are collaborating on, and this is especially true in engineering projects, whether we are engineering software or software systems. Do we all share the same Domain Knowledge, and do we all share the same Methodology and Methods, in particular Software Development Methodologies?
In many organizations, most knowledge is Tribal Knowledge
Tribal knowledge is any unwritten information that is not commonly known by others within a company. This term is used most when referencing information that may need to be known by others in order to produce quality products or services. The information may be key to quality performance, but it may also be totally incorrect. Unlike similar forms of artisan intelligence, tribal knowledge can be converted into company property. It is often a good source of test factors during improvement efforts.
When Tribal Knowledge is “totally incorrect,” I defined this as ‘Tribal Lore’ instead, because ‘knowledge’ is based on true facts, as we will see later. In practice, most organizations have a blend of Tribal Knowledge and Lore. See also, my thoughts on Tribal Knowledge.
According to Martin Fowler,
Domain-Driven Design is an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain.
In Ontology epistemology methodology and methods we see that much of the discussion is in the context of research, which is common for these philosophical concepts. In a sense, much of what any software engineering company does is Research & Development, which should be familiar terms. We have methods and methodology for defining, designing, and developing products. For example, tools like JIRA might be considered a methodology, while Epics, Stories, Tasks, and Bugs might be considered methods used in that methodology. More accurately, JIRA is an instance of a methodology, the methodology of issue-tracking.
In understanding Epistemology, we are trying to understand Knowledge, and in doing so there are two main schools of thought