在2018年第二届领域驱动设计中国峰会，我作为讲师做了一个领域驱动战略设计工作坊——再现具有实操价值的架构方案。在这个工作坊中，我将敏捷实践中的Inception与领域驱动战略设计结合起来，并引入Event Storming和用例场景分析等方法，带着大家一起糊了墙，玩风暴，算是满意地完成了战略设计的预期目标。在这次工作坊的参与者中，我欣喜地看到了业务同学的加入。这些业务同学敏锐的分析目光与业务感给我们的用例场景分析带来了极好的助力，也为整个工作坊增加了不少亮点。
我把整个工作坊分为了十个步骤，依次为：
我选择一些重要步骤对整个工作坊做一个简单的回顾。
这是一幅奇妙的图，如你所见，画中的两只手各自画着对方，当我们明晓这样一种怪异的循环时，一瞬间，仿佛这张静止的画突然流动起来，而且是一种永恒的运动，作画的两只手似乎永远无法停止。正如《哥德尔艾舍尔巴赫》一书的作者侯世达在评价艾舍尔的这幅《画手》时提到的：
《画手》给我们提供了一个更紧凑的圈，这幅画中的每一只手都在画另一只手：这是个只包含两个阶段的怪圈。
侯世达在巴赫的音乐、艾舍尔的绘画以及哥德尔不完全定理中发现了“怪圈”这个概念。
所谓“怪圈”现象，就是当我们向上（或向下）穿过某种层次系统中的（这里，系统是音乐的调子）一些层次时，会意外地发现我们正好回到了我们开始的地方。有时我用“缠结的层次结构”这个词来形容出现怪圈的系统。
我在阅读《哥德尔艾舍尔巴赫》这本书时，改不了作为程序员的积习，尤其当我看到这幅令人震撼的《画手》时，我即刻从“怪圈”想到了“递归（Recursion）”。因为“递归”正是这样自身调用自身的编程技巧。当然，一段正确的递归程序，必须要有一个必定能够到达或满足的终止条件，否则就会像《画手》那样永恒地循环下去。程序术语称之为“死循环”。
Eric Evans的经典著作《领域驱动设计》的副标题为“软件核心复杂性应对之道”，这说明了Eric对领域驱动设计的定位就是应对软件开发的复杂度。Eric甚至认为：“领域驱动设计只有应用在大型项目上才能产生最大的收益”。他通过Smart UI反模式逆向地说明了在软件设计与开发过程中如果出现了如下问题，就应该考虑运用领域驱动设计：
因此，选择领域驱动设计，就是要与软件系统的复杂作一番殊死拼搏，以降低软件复杂度为己任。那么，什么才是复杂呢？
Java的类是自定义的引用类型，是对职责相关的行为与数据的一种封装，用以表现一种业务领域或者技术领域的概念。在不同的场景，类包含的成员可能有所不同，大体可以分为如下五类：
GitChat《领域驱动战略设计》作者，《软件设计精要与模式》作者，《架构之美》评注者，公众号@逸言 架构编码实践者张逸的知识星球。
欢迎大家到我的星球做客，更重要的是让大家能看到你的真知灼见。本文即来自我在知识星球《DDD高端俱乐部》的回答。
问题：我对于领域模型如何表示始终还不太明白。按照Evans书里的说法，代码应当是领域模型的主要部分，文档、图表作为补充。另外一方面，领域模型应当是所有参与者都能够理解的，而我觉得用户不太可能去理解代码。
比如以Evans书里举的，可以超载10%这一点，书里是通过一个Strategy模式来表达这个知识，从程序员的角度看很清晰了，但是从用户的角度看，还是不太能够明白吧。
请教张老师如何看待这个问题？