代码的物理组织

同一个Feature的代码要放在一起(IDE里单独的一个工程, 或者工程里单独的一个文件夹), 这些代码要么全有要么全无的, 它们合作完成一个Feature, 如果用户不再需要这个Feature了, 可以把它们整个的痛快的删掉, 不会留下谁也用不到的代码成为系统的垃圾. 如果想看一个Feature是如何实现的, 那所有相关代码都在一起, 不需要在庞大的代码库中跳来跳去.

那么理想的情况就是: 你看看源代码树里所有工程文件的名字, 或者文件夹的名字, 就知道系统提供了哪些功能, 它可以跟你的需求描述对应起来, 无论用User Story还是Use Case, 都可以用它们的名字作为工程名或者文件夹的名字, 方便维护


流行的MVC框架缺省的物理文件组织并不是这样的, Controller, Model, View分别在不同的文件夹里面. ASP.Net MVC提供了VirtualPathProvider以及ViewEngine, 可以让我们把一个Feature的Controller/Model/View统统打包到一个project或者文件夹而运行时依然能够找到对应的action和view, 这是我们正在利用的特性


这种代码组织方式对架构的影响是什么?

这基本会导致基于插件/扩展点的体系结构. 放到更大尺度上, 就是SOA. SOA才是王道. 这个词太大了, 还是先聚焦到一个进程的应用....

1. UI如何聚合? 最终用户看到的UI, 是一个聚合的结果, 可能来自系统的不同部分. 解决这个问题的扩展点技术有客户端的Ajax, 或者服务端的RenderAction. (问题: Css应该如何处理? 不同部分的显示顺序, 布局如何确定?)
2. Feature如何沟通? Feature之间不可能一点依赖没有, 比如可能会用到相同的数据, 相同的业务逻辑. 解决这个问题的方法有Bounded Context, Context Mapping, DCI...都是一回事
3. 数据库如何划分? 不同的Feature使用自己的独立定义的数据表, 做映射和同步, 也是同样的方案
4. 如何把这些Feature组装在一起? Java平台有OSGi, .Net目前没有看到跟OSGi类似的方案. 基本是注册或动态发现的路子, 遵循开闭原则...