领域设计_业务模型不稳定

在业务模型分析时，由于受限于业务知识、业务领域间关系的不确定性，还有对业务习惯的不统一（很多业务逻辑，并不是强关联，或业务规则的时间线可前可后），导致业务模型在评审过程中受到多方挑战，最终的模型可能在不断调整，而这个调整的过程就称为模型不稳定。
模型不稳定对整个项目进度来说，是一个负面影响因素，如果业务模型不断地调整，可能会陷入某种不良循环，如果没有一位问题决策者，将会造成项目在业务建模阶段耗费大量不必要的内耗中；
如何减少内耗，是业务建模阶段必须面对的问题。对于业务模型，如果有行业法规支持，或某些规范来约束，指导思想规范大家对业务建模过程中的行为，可能会减少内耗的时间浪费，但是适当的“拉锯”也是有必要的。而这些各种规则，最终会以工艺的形式落实到每一个环节。而工艺的规范可能是需要有一个强有力、专业而又全面的团队控制，这对于管理项目的组织者是一个艰巨的任务，工艺要严格执行，但工艺本身却不能过于呆板，工艺的灵活性，工艺的简单易行也是工艺应有的特点。张弛有度，随机应变才能使工艺不断进化。
对于业务建模的成果，一定要有一个客观的载体承载才能使业务模型不断接近于理想模型。这个载体目前我们项目组有夜歌专门的业务建模辅助软件，但是软件过于结构化，可以说只是把凌乱的业务模型通过结构化方法，不业务建模的分析文档进行结构化管理，只能说是一个“业务文档管理器”，并没有业务模型分析的能力，更谈不上业务模型的“自生长”能力。或是我对软件不够深入了解，但是对于业务模型的可视化方面确实没有帮助。最简单的业务领域划分，对于公共部分的归宿问题，到目前还没有定论，导致很多公共服务不能放入系统，而其他领域在引用公共服务时不知如何引用。这必将在后期对业务模型的稳定性产生影响，而事实已经证实，应为没有引入公共服务，导致业务模型不断回补调整。再吐槽一下软件的UI设计，真是硬伤，可以说就是钢铁直男。给人的感觉就是莫名的不舒服，感觉像一个demo。
对于理性的建模载体，我并没有成熟的想法，但是其实也比较简单，就是能看得见，可交互，可仿真，最好能推演，可以通过变相查看本质，可以实现业务模型的可视化，可监测业务模型问题。当然这可能只是一些抽象的要求，如果要实现可能确实比较不易，但并不困难。我感觉整合现有市面的技术应该能实现，类似于master go加上一些数学建模和AI自学习软件，应该可以实现，而这些需要团队合作融合。如果可以实现，那就可能是彻底将软件工程带入一个新阶段。真希望有位大神能实现，带领整个软件工程行业走出自己的产业化之路，而不是总是借用别的行业逻辑来知道软件行业。

、、