最近因为项目的原因，我又在思考前端代码结构的问题。

对于后台来说，人们有微服务。对于前端来说，人们有组件化。而组件化根本就不是灵丹妙药，随着业务的复杂，前端的代码来变得越来越多，然后成为“大泥球”（即指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码）。

Backbone

在我的第一个纯前端项目里，我们使用Backbone作为基础框架、Mustache作为模板引擎、Require.js作组件化。每个页面称其PageView，而PageView之间会有一个共同的父类View。在这个父View里，我们定义了一系列的基础行为，如Render、BeforeRener、AfterRender等等，这一点上看上去和React的思考很像。组件化在这个项目里，并没有什么大的问题（当然也有效率问题）。

当时，这个项目的主要问题是前台Render和后台Render的行为差异。我们使用Java的Mustache引擎来渲染HTML给Google等搜索引擎，当用户在前台浏览时，我们使用JavaScript上的Mustache来渲染。这时问题就出现了，他们之间的行为就会有一些差异，而要修复这些差异并不是一件有趣的事。

开始的时候，这个项目很容易上手。而随着业务的发展，在一些关键的领域知识上，我们缺少的知识越来越多。尽管我们重构代码、编写测试、Code Review，但是你几个月前写的代码，你还是需要好好回想一下。有时，你也会忘记了。

React

接着在这个移动站点上线一年多以后，我们开始使用React与响应式来完成桌面版和移动版的开发（当然，它也有APP版，只是它是基于某个跨平台解决方案完成的）。对于我们来说，它很好地解决了我们的前台渲染和后台渲染的问题。我们使用Express来处理来自搜索引擎的请求，再用React的RenderHTML来返回结果。

只是我们的开发方式变成了基于契约的开发，我们提供相应的API给前端开发。只是客户的前端Leader并不给力，真的把它写成了大泥球——没有测试、没有OOP或者FP的思想等等。不过，他们倒是在组件化方面做不得不错。

Angular.js

在上一个项目没完成时，我就进入到了现在的这个项目里。虽然仍是使用契约，但是业务比原来的复杂。我们使用Angular 2.0的思考在这个Angular.js项目上，组件划分在相应对应的文件里，即其Contorller、模板、样式。

随着业务的复杂度在扩大，我们在不断的重构系统。也因此，在一些知识点上我们失去了一些对应的领域知识。在进度和架构之前，我们总是要做出一些妥协。

问题

虽然，我们可以拆分项目来把项目变小。对于越来越臃肿的代码，一个比较有效的方法就是分而治之。但是如果一个项目划分不了呢？这时，我们应该怎么办？？

我们也没有对应的领域模式可以应用在前端上，如果可以的话，我们是不是可以考虑用DSL？

对应的话，我们是不是也可以想办法将DDD的思考应用到上面？

是不是我还需要进一步提升在DDD方面的想法和能力？