六、更远的将来（有限无责任预测）
再接下来，更为迎合这种面向领域组织团队并开发的工具便会出现。但这种工具不再期望整合各个领域的实现技术（注意我不是说“开发技术”），而是提供领域间的交付标准。或者更为直接地提供交付物。更多领域专精的公司受到关注（例如现在的macromedia），大厂商开始购并更多的专属领域的公司，以整合他们的业务。
更大的平台化产品会出现，远程的、分布的、可迁移的运算理论和解决方案被普及，而与此同时的，更细分的领域带来了更多的专属工具和专精人才，项目的整体规模扩张，并由多个团队来实现（象工程的包工队一样），而单一团队中人员结构更为复杂，但团队规模仍然被保持在10人以内，以15~20人为上限。类似于测试等技术，将会作为领域而出现，类似于现在的建筑业的工程验收与监理也会出现。这些专属领域仍然有它独特的标准、技术与工具，以及提供独立的交付物。
对于整个工程来说，RAD彻底的死掉了。也许类似于建筑行业中的沙盘/模型制作公司会出现，并成为产品过程中的一环，但再也没有了在多个横向切分层面上贯通的RAD工具。基于原型理论的RAD过程，以及迭代的RUP慢慢的退出去，因为如同没有人能够提供一个楼房建筑的迭代过程一样，工程的复杂性已经让人远远不能控制单次迭代的成本。在这种规模级别之下，对层间界面的控制决定了系统的稳定性，以及能否延续开发，因此架构师在全程成为必须，而且架构的职责将更为细分，例如精密到一个数据IO界面，可能都需要特定的架构师来确认和论证。同样的，局部的失败或失效将在系统的更早时间内被发现和验证，返工在局部成为常态，但在全程却不复存在——或直接性地让整个工程失败掉。
工程越来越依赖于经验，以及由经验带来的技术模型。例如我常常提及的塔楼式建筑，并不是某个工程学家或领域专家头脑风暴的产物，而是在实践中总结的经验。工程的可复制性增强，而复制规模和环境则更趋简单（过于复杂的规则与界面是难于复制的），这一切依赖于横向分层的界面上的简洁性。
模块的复用与重构依然长期的、绝不会消亡的存在。更细的复用粒度必然从现在的对象到业务组件复用，但本质上仍然是以无业务逻辑存在的基础对象复用为前提的。界面作为组件将会在很长的历史上出现、消亡与重现。更多的层界面将以协议标准的形式出现，而在各自独立的层上，基于层间界面的逻辑组件将成批的涌现出来，“数据”仍然是他们的唯一约束与编程本质。
我们会有对计算模型的新的尝试，但本质仍与如今一致。函数式语言将会走向前台，脚本语言成为领域间的粘合剂（尽管现在在某些领域间已是如此），确定的语言将在确定的层次上大放异彩（或这也是领域语言的一个代名词），同时掌握关联的多个层次上的开发工具的专家，以及领域专长的、与程序无关的专家将成为热门。对于整个体系来说，前者主体是实现具体的业务逻辑，而后者则专注于数据定义。不过，可以想见的是，没有多少人会特定用XML带作为这些数据定义的载体，专属的数据格式将是层间交互的首选。
最后，从工程实践的角度上来讲，二十年之内，我想不会出现一本名为《软件工程之营造法式》的书。当然，某些噱头制造者或纸张贩售者的吹嘘除外。
