Domain-Driven Design is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts.
- Place the project's primary focus on the core domain and domain logic
- Base complex designs on a model
- Initiate a creative collaboration between technical and domain experts to iteratively cut ever closer to the conceptual heart of the problem.
The premise is simple, but pulling it off in the messy real world is hard. It calls for new skills and discipline, and a systematic approach.
So, What Is the Difficulty?
When technical and business experts get together to agree upon a domain model, what emerges is a consensus/compromise model reconciling the two perspectives. Most teams are agile, so being absolutely accurate about the domain isn’t deemed necessary. New perspectives and insights can be merged into later sprints, right?
However, sprints tend to build on previous sprints. Early messy assumptions about the domain fuel later messy assumptions about the domain. Developers start tackling uncertainty by making the domain more configurable, which adds to complexity. Or, the domain is made very weakly-typed so that any specialized and deep domain-specific logic requires new effort. The result is either a very loose domain model where introducing anything specific feels like programming it from scratch. Or it is a very configurable domain rife with complexity.
Then, things get worse when trying to integrate with other software. Work descends into reconciling one set of perspectives with another set. These isolated islands of domain models require complicated bridging and the integration effort to make two systems inter-operable is equivalent to making a third system.
It just doesn’t need to be this hard.
A little background. Information Science is a 2000-year old discipline and our legitimate source of inspiration. Information Technology, a new-born babe birthed just 70 years ago, was parented by the Mathematics, Philosophy, and Electrical Engineering Departments in universities. This was no accident. In the early days of computing (think of Alan Turing), an elite few schooled in these disciplines were given access to scarce computers. With the IT revolution of the 1980s, the proliferation of Internet access, and mushrooming of device diversity, this lineage gradually got lost. With the skyrocketing demand for IT professionals, schools watered down their programs. A revival of this lineage and its re-contextualization into modern concerns is required to strike a balance between business needs and engineering rigor.
The strength of this 'revival' approach is that it can accommodate both knowledge that can be explicitly represented and knowledge that can only be experienced. Consider the bicycle. The size, shape, and dimensions of a bicycle can explicitly be represented in a domain. Explicit procedural instructions of step-by-step guides on how to ride a bike can be established using text, images, and video. What can only be experienced, however, is the actual sensation of riding a bike. By using the grammar of ontologies, it is possible to represent explicit knowledge. And by using narratives of real life experience (another vocabulary and grammar coming from ethnographic field work), we can come close to describing the sensation of riding a bike. In this way, real-life situations can inhabit domain models in terms of both explicit and experiential knowledge.
This workshop instructs domain practitioners in how to build domain models that accommodate a variety of life situations. The two grammars help construct complete ontologies that consist of (a) entities that can exist by themselves (independents), (b) entities that exist as a consequence of relationships (relationals), and (c) entities that exist due to constraints applied on relationships (mediations). By systematically structuring domain models through these principles, models emerge that are greater than the sum of initial perspectives.
Is this a widespread approach? No. The workshop organizers have been developing and practicing this method for the past ten years by focusing on enabling knowledge-intensive domains like logistics, retail, telecommunications, and human resources to function in spite of poor IT. This knowledge isn’t about fulfilling computational transactions alone, but about the total knowledge needed to build complete systems.
Skill-Based and Hands-On. The two days move constantly between concept to application and back to concept for a deeper grasp.
Much of the first day is taken up with becoming literate in explicit and experiential grammar through explanations, examples, and short exercises. Then the participants are presented with some pre-researched domains and, in small groups of three, develop domain ontologies and identify ontological trade-offs (autonomy versus control for an obvious example). Participants can then think about how to apply this approach to domains they currently work with.
Who Should Come?
The workshop is for Developers, Analysts, Product Owners, Architects, ... who have already realized that making decent software requires in-depth domain knowledge and architectural trade-offs and who also realize that source code is a form of knowledge representation.
What Participants Must Bring
A sense of humor and an engineering attitude without any dogma.
About the instructors
Jenny Quillien is the Curator at the newly minted Embodied Making Institute in Amsterdam. Jenny's background is in pattern languages, ethnography, linguistics, and organizational design. She comes to Amsterdam after several decades of university teaching and management consulting across Europe and the USA. Author of numerous articles and two books, Clever Digs: how workspaces can enable thought and Delight's Muse: on Christopher Alexander's The Nature of Order.
Indranil Bhattacharya is a specialist in large-scale systems design using participatory methods and knowledge engineering. Indranil is responsible for the strategy practice in Product Foundry, an Amsterdam based organization that specializes in building high-volume and cross-domain software solutions.