（部份整理自《detail2.0總體方案-20140818》）
detail目前的問題可參見《detail2.0介紹》(2014年7月)，本文不贅述。而detail新平台的目标是提升協作效率/穩定性/擴充性，倡導商品詳情業務歸一，能橫向複用在其它detail也能運用在非detail場景。從産品到研發等各次元均展開梳理和重構，采取子產品化、sdk/api等方式來定義協作和擴充機制，并提供合成和分組兩種部署模式，以應對創新業務快速多變的需求。并在穩定性和性能方面進行統一封裝管理和工具的插件式注入，使之常态化和标準化。
什麼是子產品
子產品是具備可部署、可管理、可重用、可組合、無狀态等特性，遵循統一規範且提供對外接口的軟體單元。
什麼是平台
平台是一套完整的技術體系和架構，具備可重用、可維護、可擴充、可協作等特性，能規範研發階段的各項工作，最終支撐物種多樣化、個性化等業務目标。
子產品與平台
可以發現子產品的特性與平台所追求的特性是一緻的。子產品是微觀的具體實作機關，而平台則是宏觀上的體系架構。子產品化是建構平台的基本元素和方法，故兩者并不沖突。以子產品化理念解決目前面臨的各項問題，對系統進行子產品改造，再對子產品庫進行組織、排程，并提升除研發外其它各次元的能力以實作最終平台化。
(僅針對目前場景，普适原則不贅述)
分而治之
是解決複雜問題的有效方式，子產品化便是具體的實作方法。子產品更具可重用性、可維護性，控制複雜度、易于了解等，特别是共建(多團隊協作)和需求多變的場景下。而當今java平台，無論osgi或jigsaw等都還在發展中(細節不贅述) ，但子產品化理念和模式是通用的，隻要對系統進行良好的設計和拆分，無論采用何種子產品化方法都能受益。是以，自主設計一套輕量級子產品規範是本次平台化的切入點。
架構治理
事實證明，以口述或文檔等方式制定的技術規範都是弱規範，會被日積月累的無序行為緻使架構積重難返。是以推崇通過架構定義标準，使研發過程和實作得以規範化。但架構除了按規範去限制，也要允許在同樣規範下開放。對無序行為的治理，就如同大禹治水，并不能完全的堵也要疏。是以，子產品架構是規範的具體展現，架構會很輕很薄的對基礎部份規範，但架構更多的是支撐開放和擴充。
子產品粒度
在本方案的子產品認定中，一個子產品是無關邏輯封裝粒度、表現形式的，而是隻要可被重用、接受子產品架構管理的便是子產品。不關心内部邏輯、代碼分層等，隻關心真正對外暴露的部份是否遵循子產品規範。
平台定位
相對ic/tc/uic等，商品詳情絕非一個同類型的基礎平台，因其并非位于淘寶架構的底層，且沒有直接屬于自身的資料，而是基于後端服務通過“邏輯再封裝(注)”及“編排各服務“實作的上層業務系統。從更優雅長遠的角度，就隻應承擔後端邏輯服務的“編排者”一職，不能有具體的業務邏輯實作。
注：商品詳情的業務邏輯主要靠後端服務化接口提供，但因後端接口封裝度較低等曆史原因，仍有約10%以上(比率視各後端接口而不同)的邏輯“殘留”在detail上。雖然detail系統内部也可分出業務邏輯層、資料通路層等，但從淘寶大架構視圖分析，detail僅是各業務系統和基礎平台的表現層之一。
detail因曆史問題，有大量業務邏輯散落在包括js代碼和vm模闆在内的前端層。使得前端層複雜而又臃腫，可維護性差；也使得後端對邏輯的控制能力減弱，可重用性低；同時前後端在協作時因邊界模糊和過程依賴，使得研發效率降低。為解決這些問題，商品詳情平台化項目首先便進行了前後端分離(或稱解耦)。
針對浏覽型系統，可将邏輯劃分為：後端的業務邏輯、前端的展現和互動邏輯(統稱體驗邏輯)。業務邏輯産出業務資料，展現邏輯負責模闆渲染、互動邏輯響應使用者行為。前後端分離就是要将業務和體驗邏輯解耦，将業務邏輯完全下沉由後端控制，提升可重用性，将展現和互動的表達交給前端層負責，各司其職。
前後端分離隻将邏輯解耦，但前後端并沒有是以而失去互動，後端的業務資料接口便成為前後端的通信管道。是以平台化項目接着便對接口進行了規範性定義，包括：模型定義(入參和結果模型等)、安全機制(授權與鑒權等)、調用協定(http/rpc)、傳回格式(json/jsonp等)，并支援且推薦java本地的原生方式。
商品詳情前後端分離之後，後端在業務規則和功能領域便更具操控性，而前端也能專注于使用者體驗，且前後端在協作時隻需遵循統一規範，即可并行展開各自的邏輯實作，如下圖，職責邊界清晰，有助效率提升。
前後端分離也請關注midway
平台化項目中設計實作的子產品規範和架構，用于将整塊架構的應用（monolithic）拆解為子產品服務級應用。子產品架構是通過對源類的輕量級再封裝以實作統一管理，包括管理類的生命周期/輸入/輸出/調用模式/穩定性等。不侵入邏輯不關心類的分層和設計模式等，事實上不依賴子產品架構，如将架構廢棄源類仍能運作。
核心構成
abstractmodule 是所有子產品的基類，每個子產品加載到獨立的classloader以避免沖突
通過lifecyclelistener 可以監聽子產品生命周期
extensionpoint 是可擴充入口，以注解(@annotation)方式聲明
extension 是擴充實作的基類
代碼實作
子產品基本定義
子產品最少描述
生命周期定義
生命周期監聽(optional)
子產品容器
子產品容器主要将原本已認證子產品架構暴露的本地接口，釋出為服務化接口，提供了豐富的遠端調用協定，并對服務化後的接口進行安全包裝，支援服務化後的批量處理等功能，即未采用子產品容器的子產品隻支援本地調用。除服務化一系列的支援外，子產品容器也提供了子產品管理的鈎子，但子產品管理這部份暫時尚未實作。
配套工具
針對子產品的生命周期和版本進行管理，以及開發階段的ide插件等工具。還在開發中。
插件體系
将日志工具(如slf4j)、穩定性工具(如switch)、參數校驗、子產品流程編排等常用的類庫，以插件形式融入子產品架構，保持各子產品在開發時能使用一緻，以降低開發成本和提高可維護性。類庫在統一定義的接口下适配成插件，目的是保障如果需要替換或更新一款類庫後，子產品内的代碼不用任何改動。現日志、開關架構已完成插件化。
（近期針對子產品化進行部份改造優化，後續會針對子產品規範和架構實作再單獨詳細介紹）
詳情項目基于上述子產品規範，再對業務邏輯重新梳理、對原有代碼徹底重構，并按共建型、子產品化、可擴充的設計思路重新分層。在新的層次中，每一層内的每一點在邏輯實作後，凡向上暴露接口時均以子產品方式表達，上層通過子產品描述發現下層能力。整個平台運作在子產品容器上，子產品容器運作在應用伺服器之上。
淘寶商品詳情前輩們在多年穩定性實踐中積累了豐富的經驗，并沉澱了包括靜态化/異步化/單元化等全局架構，平台化項目在繼續受益延用的同時也在代碼層做了統一性和标準性的優化，目标穩定性治理常态化。
子產品的安裝解除安裝，保障子產品級穩定性，使得最少有一層保護
子產品被手工或自動解除安裝後，可降級其它許可版本或觸發容災
子產品内有否實作容災會在子產品安裝前被校驗，使之成為必然
在批量執行子產品時（常見場景），子產品架構可并發執行并為每個子產品設定不同的逾時時長以提升性能
因各層通過子產品架構組織，而子產品架構支援穩定性架構以插件的形式嵌入，使得各子產品能統一使用
新的平台分層裡，上層調用二方服務必需通過adapter層（此層不開放共建，主要是将外部服務進行符合子產品規範的适配并未有多餘的邏輯）。在适配層進行對外部服務的統一穩定性治理，包括開關降級/容災/逾時控制等。使之前但凡要調用外部服務就直接使用就造成需多次穩定性治理的情況得以改善，降低維護成本。adpater層内各子產品或其它各層的子產品，也能針對來源設定不同的限流閥值
detail受曆史原因也礙于代碼的分層結構和代碼的不規範性，未能實作行之有效的測試方案，是以測試工作回歸量大、重複勞動、枯燥無味、效率低下。而平台化項目針對現狀重新整理了detail的技術品質體系。
分層測試
根據代碼分層，技術品質次元也進行了對等的分層單元測試。各層主要包括：基礎服務層(如dao/util等)、業務邏輯層(如service/manager等)、對外接口層(此層進行接口級測試)、頁面展現層等。而detail場景大都是依賴更後端的服務化接口，是以在detail新平台的單元測試中為提升效率引入了powermock架構。
自動方式
除頁面展現層外，其它各層均實施自動化測試方式，而頁面展現層更多的還是需要通過手工介入方式來進行功能測試。能夠代替手工測試、找出重複測試工作是進行自動化方式的思路。而在衡量自動化測試目标時，也應從追求自動化覆寫率，到追求正确率、關注運作時間、測試腳本可重用性等，進行全方位的提升。
持續內建
基于分層單元測試、自動化測試，才能實作最終的持續內建。持續內建平台通過跟蹤代碼庫的變更而自動執行測試用例、靜态掃描等，這樣便能快速發現問題，當然也要在環境部署之前觸發，同時持續內建平台還應支援執行對應的用例，比如，隻修改了abcutil.java那麼則隻執行abcutiltest.java。将持續內建定義為常态化，設進标準流程，融入日常工作，不斷有所追求，最終高效保障淘寶商品詳情平台的技術品質。
沒有規矩，不成方圓。商品詳情平台作為一個設計完整的平台，還針對各次元定義出一套規範(或稱标準)、針對各階段設計出一套流程，以指導平台化後的研發模式。包括：子產品開發規範、提測标準、品質标準(包括業務邏輯品質标準、性能标準、穩定性标準、安全标準、可維護标準也包括運維)、釋出流程(含緊急釋出流程)、線上問題處理規範，這些規範和流程面向參與平台建設的所有前後端開發、測試、運維等各角色。
規範是必需要建立起來的指導原則，在通過商品詳情平台化的實踐後，針對規範的落地也更有理由相信：
1、設計再良好的架構，也是需要依靠合适的組織結構去保障的；
2、架構的認同、執行、維護，最終需轉變團隊成員的思想，這是一個過程；
3、盡量将規範和流程用以工具、示例等更形象更直接方式表達。
另一方面，在共享共建大背景下，平台在搭建之初也針對共建進行設計，無論是共建理念定位、子產品邏輯結構、實體部署方式，再到各次元能力的協同。以下便是經過子產品化改造後商品詳情平台的共建研發模式：
商品詳情新平台提供兩種協作模式：
1、 獨立子產品級共建
預設共建方式。各方基于aone二方庫進行共建，一個二方庫即一個子產品，二方jar包即子產品單元，二方庫内代碼實作需符合子產品規範才可被識别和部署。該方式在研發過程和部署方式上更靈活，更可管理，共建方的可控性更強，但對于detail主維護團隊所提供的平台底層擴充能力(即sdk)要求較高。
2、 源碼分支級共建
多人基于同一個源碼工程，通過開多個分支的方式，在各分支上實作業務邏輯，最終各個分支在整體合并後進行部署。優勢是允許從底層能力至上層業務更大範圍内進行編碼，更具連貫和順暢性，但缺點是分支和流程沖突大難以協調、業務了解能力和編碼實作習慣各有不同，容易逐漸造成架構被腐蝕。
商品詳情新平台更加關注“共建方體驗”，在新架構和新研發模式的基礎上，共建方将得到如下體驗和權力：
平台邏輯架構和部署實體結構，因所面臨的問題領域和解決方式各不相同，是以不能互相限制對方的最終形态，即不能因為平台邏輯架構而綁死最後部署結構，這是平台化項目的架構設計基本原則之一。更何況在業務高速發展，需求多變，團隊協作的特定場景，更是要求部署模式也一樣的靈活，按需定制，可組合。
成功案例
農業detail全部承載
挑食detail全部承載
蝦米detail全部承載，暫未上線
旅行detail部份後端接口
等等……
其它業務場景
高速業務場景：針對大型的垂直業務或快速發展的業務，在除主站detail叢集即主平台外，隻需采購所需的業務子產品（也可遠端調用），就可以在獨立叢集再進行部署，業務方隻需關注自身子產品的開發疊代，其餘的子產品包括基礎架構均由detail團隊負責推送更新，便可自行掌控所有權限和節奏，還能共享同一套cdn靜态化體系。如當業務成熟、需求逐漸減少，認為有必要時，隻需向detail團隊提供子產品即可回歸主平台。
無線終端場景：某app或html 5端需要部份接口，detail直接提供遠端服務或将所需要的子產品接入mtop
非詳情的場景：某頁面需展現sku，可将detail前後端的sku子產品拿走，從後端資料到前端渲染及sku選擇計算就統統包括；某頁面非商品詳情但需展現賣家檔案可結構略不同，則複用賣家檔案子產品，前端部份自行實作。複用時可直接拿走賣家檔案子產品包自行部署提，也可找detail團隊先溝通後直接調遠端服務
該文章來自阿裡巴巴技術協會（ata）精選集