module/目录

在module/目录下存放业务模块代码只是一个约定，实际上业务模块代码可以存放在根目录下的任何地方。新增模块，实际上就是新增目录以及所属类型，例如新增首页模块”home_pages”且属于客户自定义分类”custom”，目录结构如下： custom：表示一个可读性强的目录名，说明目录下的业务范围。
home_pages：模块名
home_pages.info.yml：特殊文件，只要出现”.info.yml”文件，该目录将被声明为一个模块。
home_pages.routing.yml：特殊文件，定义该模块的路由器。
home_pages.libraries.yml：第三方动态库，支持引入JS、CSS
src：PHP代码，遵循PSR-4规范。
js：拓展目录，引入JS脚本代码。
*templates：前端模板目录，存放前端代码，格式这里为TWIG。

关于前端代码：Drupal8引入了twig模板解析引擎，因此前端代码并不是直接写HTML，而是通过写twig模板文件，然后在运行时动态生成HTML文件。关于TWIG引擎的引入，可以查看Drupal8的核心依赖库目录“vendor/”。Drupal8遵循MVC设计风格，TWIG文件仅处理View层。

关于PHP代码：Drupal8重写后，遵循MVC设计风格，PHP代码作为Controller逻辑控制层，负责控制逻辑转发。在路由定义中，每个path都会有一个处理器，如果处理器类型是_controller，指定的PHP源文件类也是继承了ControllerBase基础类，处理页面的初始化渲染参数。

关于JS代码：Drupal8通过逻辑控制类_controller可以动态载入JS动态库，也可以利用TWIG语法决定JS在模板文件中的加载顺序（{{ attach_library(‘home_pages/js-lib’) }}，这里的js-lib引用*.librares.yml文件内定义）。通过这个方法，可以将TWIG模板类文件和前端处理脚本分离，这里的JS便是MVC的Model层，处理各类后台数据。

这里的MVC不是严格分离的。Controlelr也可以传递渲染的参数，而TWIG也可以处理后台数据，JS自然可以处理model内部标签，遵循MVC设计仅是一种开发习惯上的约束条件。通过图例演示他们之间的关系： 简单流程，Http请求访问该模块，通过routing.yml路由器定位到逻辑控制器，通过逻辑控制器寻址找到模板和视图。TWIG负责展示内容，Library引入脚本处理视图（这里可以引入Vue框架）。