上下文说明

　　领域驱动设计中有个一非常重要的概念，叫界定上下文。目的是对当前活动的范围作出限制性说明，所有分析、验证、结论，只有在指定的界定上下文中，探讨它们的合理性才有意义，一旦超出了这个上下文，讨论他的合理性和正确性，就直接跑题了。

　　应用DDD领域驱动设计，就是为了更好的分析业务本质上的知识、关系、流程。最终的输出与客户的需求不一定完全一致。因为客户虽然能够熟练的完成工作，但很少有人能总结出自身业务知识，及对业务流程的合理性作出深入的分析和评价。企业的人员岗位配置，人员素质，所使用的信息化工具，决定了大多数企业业务流程，具有一定不合理性，但还能正常运转。随着企业的发展，很多业务流程中的不合理性开始发挥作用，会让企业陷入泥潭，步履维艰。所有开发企业应用的出发点，应当首先是找出业务本来应该是怎么样，然后通过开发信息化工具作为支撑来实现，让业务流程回归到它合理的状态。这是我对开发企业应用的理解和选择领域驱动设计开发企业应用的目的，也就是DDD的上下文。

　　解决了业务分析设计的问题，接下来就是技术落地的问题，再好的设计最终不能实现，就变成了纸上谈兵。领域驱动设计的方法之所以没有被广泛采用，就是因为其对于开发者的素质要求高，很多知识不可以复制，只能凭经验。软件的开发过程由流水线生产，变为艺术品的创造，对大团队的管理和配合提出了更高的要求。上坡路就是这么艰难，但必须去挑战。最开始，我采用传统的需求分析方法，三层架构技术开发生产企业的物料追踪管理软件，依照客户的需求做，等到上线后才明白，这不是客户所需要的东西。需求分析方法和思路有问题。接着采用Apworks框架，基于DDD领域驱动设计的思路，重新分析和设计软件，解决了需求分析和功能设计的问题，但是遇到了技术落地的问题，现在终止了。后来发现了ABP框架，经过分析和研究，发现它对所有之前遇到导致技术难以落地的问题，都有非常完美的解决方案。

　　DDD是可以对症的好药方子，ABP是货真价实的好药材，能解决问题吗？不行。还有很重要的一步，服药的方法，只有把这一步也解决好了，才能修成正果。接下来的系列博客，将以采购管理模块的开发为依托，介绍领域驱动设计的业务分析方法，并应用ABP框架支撑起业务分析的输出，最终实现一个梦幻般的采购管理模块。