11、CatalogIndex
跟商品相关的几种索引（价格、属性等等）的处理模块，商品是系统的核心组件，处理商品索引相关的模块自然也是核心模块，必须是开启状态。
12、CatalogInventory
核心模块之一的“库存”模块，管理者Magento的商品库存相关的功能。
Magento的库存逻辑，主要通过两个字段来控制：库存数量（Qty）和库存状态（Stock Availability），理论上只有该商品库存数量大于0并且库存状态是In Stock时，这个商品才是前台真正可以售卖的。这俩字段有一定的关联，当一个在售的商品的最后一件被买走之后，商品库存数量变为0的同时，库存状态会自动变成Out of Stock，但是反过来，商品库存数量由0变成正数时，库存状态是不会自动变成In Stock的。商品库存数量大于0同时库存状态是Out of Stock的一个状态，其实很好理解，对于一个商家来说，一件仓库里有货的商品，我暂时不想卖（因为各种原因）是很常见的一种情景。
电商系统的下单扣库存的逻辑，一般分成两种，订单生成马上扣库存，或者订单在线支付成功(货到付款另议)才扣库存。前一种的缺点是容易被人攻击（重复下单而不付钱，占住库存导致真实用户无法购买），优点是不会超卖。后一种的缺点是同时购买同一件商品的用户太多时容易超卖（订单生成到付款完成中间有时间差，这个时间段内其他用户依然可以下单），优点是不怕有人通过恶意下单来攻击。据我所知现在国内包括淘宝在内的大部分电商主要是采用前一种方式的，在此基础上通过一些限制手段来防御攻击，比如未付款订单一天后自动取消（活动商品15分钟未付款取消订单等等，比如双十一），单个用户当天最多只允许购买两件相同商品等等。
既然是“核心”模块，CatalogInventory当然是必须开启的。
13、CatalogRule
商品促销规则模块，利用Magento的规则引擎，针对商品级做一些价格上的促销打折设置。强调商品级的设置，是为了区别于后面会讲到的购物车促销规则（SalesRule）。CatalogRule模块通过后台设置的规则，前台生效的方式是直接影响商品的最终单价（final price）。
Magento有一套相对于其他B2C系统很有特色的条件（Conditions）规则引擎，一条完整的规则（Rule）基本上由条件（比如所有男装）和操作Actions（打8折）两部分组成。其中条件部分，通过系统的规则引擎，可以设置一重或者多重的条件（通过与或非的逻辑），从而变化出无穷多不同的规则。
CatalogRule设置的规则，保存完之后还必须应用（Apply Rules）才能生效，这里涉及到了价格索引的更新。另外，CatalogRule的规则，应用之后的有效期只有一天，需要开启cron job来每天自动应用一遍来保证规则在前台正常生效。
CatalogRule模块的功能不一定每个用户都用得到，但就算用不到，因为一些代码与其他模块有牵连，所以这个模块没法关闭，从这点来说，CatalogRule也算是“核心”模块了。
14、CatalogSearch
商品搜索模块，这个模块功能上很好理解，所有电商网站都必备的搜索商品。可以拎出来讲一下的，就是Magento的搜索机制上自带的两个小变化：同义词（Synonym）和跳转（Redirect）。
如上图，设置“裙子”的同义词为“裙”，当前台用户搜索“裙子”时，展现的结果其实是搜索“裙”的结果。设置“男装”的跳转链接为http://127.0.0.1/magento/men.html（我本机项目的man分类页），当前台用户搜索“男装”时，会自动跳转到设置的url页面。
实际网站运作中，自带的搜索功能可能不能完全满足需要，比如用Magento做中文网站，自带的搜索功能无法做到中文分词，这个时候就需要在自带功能基础上做一些二次开发，引入Solr 、Sphinx或者Elastic Search之类的全文检索引擎（或者使用最新版本的mysql5.7，原生支持中文的分词）。
如上面所讲，搜索是电商网站的标配功能，那么CatalogSearch模块自然就算核心模块了，必须开启。
15、Centinel
Centinel模块提供了3DS（3D Secure Credit Card Validation）支付验证服务（详见百度百科），这玩意依赖于Visa或MasterCard的信用卡。如果做中文站，那Centinel模块毫无作用。如果做英文站但用不到3DS支付验证，那么Centinel模块也是没用的。
老实讲我没有实际用过这个3DS，不过从身边了解的情况来说，大部分Magento用户好像也没在使用这个，如果你也一样用不到它，那就把这个模块关了。
16、Checkout
核心模块Checkout，字母意思是结算，实质上从前台页面来说，这个模块主要管理着购物车和结算两个页面。具体来说包含的内容有购物车，优惠券，结算地址，支付方式，配送方式，结算条款，访客结算等等。
Magento原生自带的Onepage Checkout，实际使用时是通过点一个个下一步（地址-》配送，配送-》支付方式）来完成整个结算流程的，这种方式具体好不好有争议，我的个人意见是，至少在做中文网站时，这种结算流程是不太符合国内的常规做法的。有一点可以佐证说自带Onepage Checkout有争议的是，有很多Magento第三方插件开发的公司，开发了各种各样的所谓One Step Checkout来取代自带的“多step”。
有点特别的是，Magento的整个结算流程中（从加入购物车到最终提交订单），各种临时信息（购物车里的商品，选择的地址、配送方式、支付方式等）并不是存在session里而是存在数据库里的（以sales_flat_quote前缀的一系列表），在session里存的只有quote的id，实际应用中可以通过这个id从数据库取出所有相关的数据。关于quote的一些数据模型主要在Sales模块里。
Checkout模块毫无疑问是核心模块，是不能关闭的。
17、Cms
如字面意思，Cms模块就是一个小型的内容管理系统，管理着网站上所有需要后台手动编辑的“静态”内容。通过后台管理的cms内容分两类：Pages和Static Blocks，Pages代表一个个独立的页面（About Us、Company、Customer Service。。。），Static Blocks是可以放置在各个页面局部的静态块，通常用来放放广告banner之类的。值得注意的是，Magento的首页也属于cms模块来控制的，是Pages里的其中一条数据，对应的控制器是cms_index_index。另外，上面为什么给静态两字加了引号，因为实际上在cms里的内容也可以是“动态”的，比如
{{block type ='catalog/product_new' name="home.catalog.product.new" template ='catalog/product/new.phtml'}}
实际的网站运营中，可能有需要对静态文章划分一些分类的需求，原生的cms模块是没办法满足的，这个时候你可以选择在cms模块基础上做一些二次开发，或者也可以直接简单的装一个免费第三方插件来满足这个要求，这里我推荐的是AW_Blog。
Cms模块当然是核心模块，关了的话连首页都没了。
18、Compiler
编译模块，Magento的“编译”跟编程语言（比如java）的编译不是一回事，Magento的编译的实质，是把code目录下的各种php类文件，全部复制到/includes/src目录下。 在编译开启的情况下，系统运行时会去/includes/src目录找所需要的类文件，而不是去code目录下的community、core和local目录找类文件。 因为/includes/src目录下的类文件分布基本是同一个大目录的，相比于源文件分散的分布在各个模块的Block、Helper和Model的多层目录结构，编译后的系统能够更快的找到所需的类文件，从而提高了系统运行的效率。按照监测的指标来说，编译后的Magento系统，运行时对IO的消耗更低，这一点在网站有高并发的情况下，编译前后对服务器IO的影响会更明显。
使用Magento的编译有一个前提，就是做二次开发时，要严格按照Magento的框架结构要求来写，或者说要遵循Magento的自动加载（autoloader）机制。因为php很自由，理论上开发者不遵循Magento的框架，也可以二次开发出各种功能来，比如require_once一个绝对地址的类等等，这种情况下，编译之后系统就不一定还能顺利找到所有希望找到的php类了。当然实际工作中会发现，在跟很多第三方Api做对接时，第三方一般都会提供现成的sdk类库来帮助你开发，这种时候，是直接简单的用现成SDK来开发（不遵循Magento的架构），还是麻烦些把类库改造成标准Magento类来开发，这个选择就是自己衡量了。
Compiler模块不用的话是可以选择关闭的，比如二次开发之后已经没法保证编译后正常运行了，那不如就把这个模块关了。
19、ConfigurableSwatches
ConfigurableSwatches模块是magento 1.9.1.0版本开始才加的新模块，不过模块的功能对广大Magento用户来说却并不陌生。对于服饰类的电商网站来说，购买衣服时可以通过点击不同色块来选择想要的颜色是个很基础的需求，不过很可惜的是，虽然Magento提供的“Configurable Product”这种商品类型很好的做到了对服饰类商品数据结构上的支持，但在前台商品页的展示层面，原装Magento的颜色选择方式只是一个下拉框。在之前的版本中，想要做到类似淘宝那样的色块选择模式， 要么自己做二次开发来实现，要么选择现成的第三方插件（Magento的官方市场里，名字类似Color Swatch的插件有好几十个，可见需求的旺盛）。 这个情况直到1.9.1.0版本，官方终于把这个功能加了进来，算是补上了Magento1.X版本的一个缺憾（此时距离Magento开始在市面上流行已经过去了好多年
）。 
不过呢，自带的功能不一定是最好用的（这个原则不仅仅针对ConfigurableSwatches），在实现色块选择的这个需求上，ConfigurableSwatches模块所实现的效果和管理方式并不一定比那些第三方插件来的好用。举个栗子， ConfigurableSwatches模块前台显示色块图片的原理是图片的文件名与颜色属性的颜色值一致，比如block这个颜色对应的图片是media/wysiwyg/swatches目录下的black.png，这种对应方式显得相当不灵活。再比如，淘宝的色块选择其实显示的图片并不是纯色块，而是该颜色商品的缩略图，要实现这种展示方式，ConfigurableSwatches模块的死板的色块对应关系也会无能为力。
ConfigurableSwatches模块是可以关闭的，如果你不需要用到（比如只卖食品，不卖衣服），或者更喜欢第三方插件的展示和管理方式。
20、 Connect
Magento能够在全世界流行起来，除了系统本身做的不错之外，庞大且功能多样的第三方插件市场是很重要的推手（https://www.magentocommerce.com/magento-connect/）。Connect模块就是用来帮助Magento用户下载官方插件市场的插件的，或者说是用来下载官方插件市场的免费插件的，收费的插件一般需要到插件开发商自己的网站上去买。 除了下载插件，Connect模块的另一个功能是就是打包插件。我们这些Magento用户，除了可以去官方市场找插件，也可以把自己写的独立模块打包成一个插件发布到官方市场去。
Connect模块这么有用，是不是就不能关闭呢，答案是看情况。一个规范的网站文件更新流程中，所有的网站代码文件都应该是经过版本控制的(SVN或Git)。如果在一个Magento的生产环境后台直接用Connect模块在线安装插件，插件的文件就会未经版本控制直接放到生产环境的服务器银盘上，这是对流程的一种破坏。在网站已经上线的情况下，在我看来，比较好的操作方式是，在开发环境通过Connect模块在线安装插件，然后然后经由版本控制把插件的代码文件提交更新到生产环境（收费插件的话，本身就需要购买后下载文件手动安装）。所以，生产环境的Connect模块是可以关闭的，而开发环境则可以保留这个模块来在线安装第三方插件。
