阅读这边文章的你，可能与我有相同的想法：致力于开发高质量的软件的同时，降低程序中的bug数量--貌似不存在没有bug的软件产品（世界上不存在完美），软件一直在尝试模拟人类社会的某种活动，这个模式提前注定了软件的悲剧----那就是一直在模仿，从未有过超越，一旦软件无限趋近与人类的实际活动时，人类又会出现更加成熟、简洁的社会活动。目前暂时无解......所以，设计出能够精准表达人类活动意图的软件模型显得有为重要了。
DDD （领域建模）作为一种软件开发的方法论伴随者这种呼声应运而生，很庆幸自己在几年前就开始解除DDD，并且在大大小小的项目中不断的理论联系实际，随着系统的复杂度越来越高，越能体会到DDD的强大与优美，基于DDD架构的软件工程如同一台设计完备的机器，具备精密的同时还具有一定的扩展性，你可以把他想想成为汽车设备的引擎~~~~等，有些写不下去了~~~ 正所谓：通过DDD完成的恰恰就是软件的工作方式，让软件不再是冰冷的代码，而是注入了一种生命的张力。
我们的目标是创造一个可测试、可伸缩、可扩展、组织良好的软件模型，通过代码在实现其模型，在这个过程中DDD为我们提供战略与战术上的全访为指导，（战略可理解为软件的宏观层面，战术则意味者某一些具体的软件实现本身.....）,想到 井上雄彦 的《灌篮高手》年近40岁的我已经热邪沸腾啊。这些年在努力的坚持与贯彻DDD，最大的感受之一就是可以跳出程序员的思维模式，并且可以讨论、聆听、裂解与发现业务专家的业务讲解，尽管依然无法摆脱技术的限制，但是可以做到有所侧重，至少在需求阶段可以聚焦于 用户如何理解与使用软件本身，而不考虑其软件实现。用DDD的术语来讲，就是好的软件团队是要配置领域专家，这些领域专家会用他们固有的行业术语向你（我们程序员）描述业务本身。这里再讨论深一些，搞火箭出生，顺道搞搞电动汽车的美国疯子-特斯拉老板CEO 马斯克，这厮思维模式一种与众不同，常常采用第一思维来思考问题，第一性思维来思考问题，什么是事物的的第一性，这是一种很不错的思维模式，大家可以再业务讨论的过程中有意识的锻炼自己，尽管不一定是正确的，至少再探索事物的道路上，走的也许会比别人更远一步.......
好了，还是回归我们的DDD吧，领域专家可以帮我们建立更为专业 与 更加接近业务本源的领域模型，所谓领域模型，其实就是特定业务领域的软件模型，这些领域模型是通过一系列的对象模型构建而成，这些对象不仅仅是数据的持有者，还包括了 行为本身，以及基于行为叠加的复杂业务逻辑，从而敬重的定义与描述了 业务含义本身。 好了 这里提到了OOP，面向对象编程，基于DDD是无法绕开这个关卡的，OOP是构建DDD的最小单元，这时也许会有人产生质疑：不就是OOP吗？用Hibernate这么多年了，难道不是OOP？ 再这里，我只能说，Hibernate仅仅解决了OOP数据层持久化的问题，如果更加精确一些，Hibernate所代表的应该是 DTO（数据传输模型），如果一定要用DTO认为是OOP，只能说 那是一具没有灵魂的皮囊，徒有其表而已。理解OOP，选哟时间的积累与沉底..... 也许有一天，你对OOP有一种全新的认知，仿佛一些皆可对象化....恭喜 再OOP的道路上前进了一大步......,如果用DDD的语言来描述呢？DTO模式的对象 定义位 “贫血模型”，想想看，基于贫血模型构建的软件工程~~~健康度可想而知~~随时都是摇摇欲醉啊~~~，我可以举出一些实际的雷子来证明一下所谓的“贫血对象”：
1、我们再基于OOP编程时，所谓OOP是不是主要实现的setter与getter方法呢，而且针对对象自身基本没有业务逻辑，所谓的业务逻辑都被外放到 service 层
2、软件组件是否包含了系统主要的业务逻辑呢？并且多数情况下需要调用 setter与getter方法实现，所谓的对象几乎没有 构造函数，对象内部没有什么的修饰符：例如 final 修饰那些不可变属性
3、大部分程序都是用MVC，M层实现setter与getter ，service层实现所谓的业务逻辑、V层实现对外http服务的发布？
如果上述满足任何两条，恭喜你的代码基本都是 “贫血”的。。。。看来 Hibernate 等ORM框架对我们影响太深渊了，万恶的Hibernate.......也许是我对这个框架天然的排斥把，至今我在维护的项目依旧采用这个，期间经历的种种无奈，也只有我能体会把..... 难道对象没有自己的行为么？为什么把对象该有的行为定义到service中，对象是用来干嘛呢？难道仅仅是DTO么？ 不要吝惜代码了~~~ 让真正的OP回归把~~~ （后面没独立章节介绍），例如我们常常炫耀自己写了一个完成的函数 updateXXXX（） ，这个方法可更新任何数据到数据库中........ (what a fuck.....),直接写一个 CRUD 接口得了，一个好的对象，至少要明确那些是不可以变化，那些是可变化的，为什么会有这样子的变化，背后的业务逻辑是什么...为什么或者这样子~~是否还有更加好的解决方案.....这才是引入DDD后需要思考的问题.......
为什么引入领域专家呢？应为程序员与实际业务之间，有一条天堑，我们IT这个行业仿佛可以对接任何一个行业，但实际而言呢？隔行如隔山啊，作为开发者能够传递真正业务价值的软件模型与开发软件之间有所差异的，具有真正业务价值的软件模型能够更好的符合业务战略，并且能将更好的竞争优势融合到解决方案中，而这些业务模型都是与业务相关的 ，好的软件模型能够指导、引领业务自身并实现自我进化.......，但是现实中呢？很少能够遇到或者配合专业的领域专家，就算是软件需求团队，也需要再某个行约浸淫N年，业务勉强可以称其为领域专家.......于此同时，领域专家的重点在于业务本身的交付与使用，我们程序员的思维重点是技术如何实现，这种天然的矛盾体，基本可以定性 业务与 技术 天生的冤家~~~~ 这也是软件行业需要解决的老大难问题~~~而DDD，则强调把领域专家与开发人员聚集到一起，一起讨论、分享、构建业务模型，这样所开发的软件能够精准的实现业务本身。
谈到目前呢? 这些都是再讨论DDD的引入解决什么问题，其实，首先解决的是程序员如何用业务的思维来理解业务，而不是用技术的思维来理解业务，引入DDD的首要目前是构建 通用语言以及所谓上下文，所谓通用语言不一定是UML，基于某种场景下让领域专家与程序员在业务沟通层面能够达成一致即可，切记不要犯这样的错误：你以为你以为的就是你以为的吗？不要自大，要不耻下问，特别是站在我们程序员的立场，在业务专家面前，我们都是小白，尽管人家领域专家也许也是个90后的小弟弟或者小妹妹。。。。。。目前按照我的模式可以进行如下的方法：
1、构建统一的沟通上下文以及专有名词的定义，这个很要命，常常出现你以为你以为的就是你以为的命题，这方面业务专家具有主导权，一千人眼中有一千个哈姆雷特，特使在业务专家眼中，只有唯一的哈姆雷特.........
2、在第一部的基础之上 构建统一的术语表，并且文档化，好记性不如烂笔头啊~~~ 我年龄大了 有些记不住了~~ 好汉不提当年勇，也许当年也没有勇过
3、把这些术语进行有效合理分分类，使其在特定的语境下，各自有独自的专有含义，例如 订单（术语），在不同的环节上 购物车、下单、邮寄等包含的侧重点有所不同.......
4、上下文本身，就是完成某个具体业务的语境，脱离上下文，专业术语也就没有意义了
切记，上述的步骤是通用的流程，抛砖引玉，在实际的实践中，不要拘泥于形式 核实自己的就是最好的~~~ 让DDD 开始陪伴团队一起成长把......
一个好的企业应该尝试使用DDD驱动来推动软件与业务的发展，如果作为程序员的我不在热衷与技术本身时，需要把眼界放的更加宽广一些，不管用什么样的技术，最终要想用户提供业务实现的价值，（可惜做不到，至今依旧时Java的粉丝......），尝试构建领域模型会给软件团队以及公司带来丰厚的回报：
1、构建立刻一个有用的领域模型，这一点很重要
2、基于上述的领域模型，业务得到了更加准确与清晰的定义
3、领域专家可以位软件设计做出相当大的贡献，软件不再时IT的宠儿
4、为最终的用户提供更加良好的用户体验
5、更为清晰的模型边界（这个有些难以理解，慢慢熟悉），DDD 包含的内容很多，OOP、聚合、核心域、值对象、上下文 持久化等，互相协作而产生了边界以及边界之间的协助
6、更加专业可扩展的软件架构以及 敏捷、迭代与持续构建
当然DDD在引入不是没有门槛的，而是门槛时可变化的，没有什么时绝对的，引入DDD也是需要一些代价与觉悟的，如果这点服务都没有，那么DDD更多的是纸上谈兵......如下的几点挑战是无论如何都无法回避的：
1、是否为创建领域模型腾出时间与精力（这一点很要命，大多数企业都比较短视，认为软件就是线性发展 ，从未奢望过 指数级发展，也无法腾出时间各研发与业务进行更加完善与全面的讨论）
2、持续的把领域专家引入项目，伴随项目的发展一起发展，没有一个领域专家可以搞定软件的全部，所以这个也是很重要
3、程序员用领域模型的思维来思维软件研发
上述的几条，基本都花费在软件前期的论证与讨论方案中，当然在其中首先需要一个能够基于DDD思维模式贯彻的Leader。。。。需要一个方法论的指引.......
DDD实践是一个长期的过程，但是总要有第一次的尝试，不要担心失败或者走弯路，良好的DDD可以让让软件更加趋近本身~~~~
今晚难得~~没有业务的打扰~~~吃饭至于向写点什么来记录我DDD的实践之路~~~~ 后续有连载~~~ 时间到了 该给娃洗澡了~~~~人到中年~~身不由己啊~~~~
DDD是个好东西，它是一套方法论，不是具体的技术，是程序员思考这个世界的一种可行性方案，说多了都没用，实干才是王道~~~~此情可待成追忆.......
621
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
