In any system, there are at least two domains: the IT domain and at least one business domain. Business stakeholders usually look forward to a solution that solves problems in their domains. Instead, they sometimes get a system that solves the problem in the IT domain, and are forced to learn IT concepts, such as tables and data queues, in order to use the solution. That is an example of the forced domain anti-pattern.
There are problems caused in the system development, adoption, and evolution when the IT domain solution is imposed in this way. Tools such as DSLs and structured walkthroughs, along with deep architectural reviews and glossaries, are used to get everybody working on architecture, speaking the same language, and solving problems using the same concepts. This presentation deals with the domain structure, shows the problems of the forced domain anti-pattern, and offers tips, tricks and strategies to avoid getting a "pig in a poke."
This presentation was given at SATURN 2011 in Burlingame, CA.