承前：大型系统的支撑，应用系统开发思想的变迁，DDD实践切入点(一)，DDD实践切入点(二)，模型构建
模型完了，架构之前说了选择经典DDD的架构，需求目前还不需要分析特别细，而且架构部分受需求的变动影响不大，现在就可以开始构建代码了，主要是先完成主体框架和典型功能。框架的目标主要是将申请单通用的功能，如申请单维护、提交和通用映射封装；读写分离，非模型内部的查询独立；尽量使程序员开发新流程时，只需要完成UI，DTO，特殊的映射和实现抽象核心。
准备借助TDD方式由单元测试进一步使用集成测试驱动开发，使用T形集成结合功能导向集成的方式增量集成迭代开发。选择功能导向集成是因为应用层功能比较明确，每次集成新功能比较方便。T形集成建造并集成一个直插底层的块，以验证架构的假设，然后建造并集成系统的框架。
功能导向集成
T形集成
关于用例，用例是对需求中情景的描述，但并不是必须的，有需要时可以选用。此处用新增申请单作为示例。
用例UC1：新增申请单
范围：BSS系统
主要参与者：销售，各级事业部行政部领导，BOSS，工时管理系统，商机管理系统，财务系统
涉众及关注点：
——销售：希望方便录入，必录项明显提示
——领导：查看方便，直观(例子，不要吐槽)
前置条件：销售人员必须经过认证
成功保证：存储单据信息。
主要成功场景或基本流程：
1.销售人员选择商机
2.填写项目及相关信息，上传附件
3.验证录入的信息是否正确
4.保存
销售重复2~4，直到信息填写完整
5.提交
扩展或替代流程：
*a.系统在任意时刻失败
1.销售重新登录
特殊需求：
-界面自动最大化
技术与数据变元表：（是在举不出例子了。。。）
发生频率：肯能会不断地发生。
未解决问题：。。。
其中，参与者的寻找容易出现疏漏，可以依靠一下问题验证：谁来启动和停止系统？谁来完成用户管理和安全管理？谁来完成系统管理？系统要相应时间事件而完成活动，“时间”是参与者么？当系统失败时，是否存在监控进程将系统重新启动？软件升级是如何处理的？是推模式还是拉模式？除了人作为主要参与者，还有其他外部软件或自动机器系统调用该系统的服务么？谁来考察系统活动或性能？谁来考察日志？是否可以远程检索？系统发生错误或故障时应通知谁？
类图的话，暂时不画了，因为前面画了好几个了，用一个顺序图结束这篇随笔，代码的话相信看到这的人也不会在意，暂时可能还无法开源，所以就不贴了，下面图上有个争议，仓储该由应用层调用还是领域服务，我现在觉得由应用层调用更合适，不过目前不是大问题，所以先不修改了，而且应用层的代码程序员可以看到，我本身不是很希望他们看到，暂时就先这么着吧。
上面这图不是很理想，有当时的理解问题，也有为了限制程序员的原因，下面是和群里讨论后，感觉比较理想的情况
