From domainlanguage.com:
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.
Solution
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.
The Workshop
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.
Workshop style
Skill-Based and Hands-On. The two days move constantly between concept to application and back to concept for a
deeper grasp.
Workshop Organization
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.