[#11] Somehow missed this commit from Rob

* Updated changes based on PR #15 * Some additional tweaks by Nick (cherry picked from commit 6da03b0)
Sitecore · Oct 24, 2019 · 0fcd977 · 0fcd977
1 parent ecfbfe9
commit 0fcd977
Show file tree

Hide file tree

Showing 10 changed files with 27 additions and 28 deletions.
diff --git a/helix/introduction/definitions.rst b/helix/introduction/definitions.rst
@@ -8,7 +8,7 @@ Module
     thereby business centric – way. For example, when the company asks that 
     their Sitecore solution contains website search, all assets, business
     logic and configuration relating to search belongs to the Search module. 
-    These assets can also span across the different target subsystems that make 
+    These assets can also span across the different target services that make 
     up a complete Sitecore installation. For example you could have a module 
     which contains functionality that runs on both the Sitecore website and the 
     Commerce Engine.

diff --git a/helix/principles/architecture-principles/dependencies.rst b/helix/principles/architecture-principles/dependencies.rst
@@ -68,7 +68,7 @@ context this includes not only references between C# classes and .NET
 assemblies, but also references from code to Sitecore templates and
 fields, references between templates, references from templates to
 renderings, references from HTML mark-up to CSS, calls from the Website
-through to other subsystems like the Commerce Engine, and so on. Therefore,
+through to other services like the Commerce Engine, and so on. Therefore,
 when working in a modular architecture environment with Sitecore, make
 sure you constantly keep an eye out for loose coupling or implicit
 dependencies, and actively ensure dependencies are as explicit as

diff --git a/helix/principles/file-structure/modules.rst b/helix/principles/file-structure/modules.rst
@@ -3,7 +3,7 @@ Module structure
 
 Each module has the following structure, note that not all modules will contain all of the elements seen below. Only the elements
 that apply to that module should be created, for example not all modules will require serialization or have code that executes on all
-of the subsystems.
+of the services.
 
 ::
 
@@ -14,7 +14,6 @@ of the subsystems.
             /tests         // Unit or other test types for the module
             /commerce      // Houses the code for the plugin that runs on the Commerce Engine
             /xconnect      // Houses the code for plugins targeting the xConnect website
-            /client        // Houses jss client-side code
 
 .. admonition:: Sitecore Helix Examples
 

diff --git a/helix/principles/index.rst b/helix/principles/index.rst
@@ -45,7 +45,7 @@ solution.
     templates/index
     layout/index
     configuration/index
-    subsystems/index
+    services/index
     multi-site/index
     language-support/index
     security/index

diff --git a/...les/subsystems/_static/CommerceEngine.PNG → ...iples/services/_static/CommerceEngine.PNG b/...les/subsystems/_static/CommerceEngine.PNG → ...iples/services/_static/CommerceEngine.PNG
diff --git a/...les/subsystems/_static/CommerceModule.png → ...iples/services/_static/CommerceModule.png b/...les/subsystems/_static/CommerceModule.png → ...iples/services/_static/CommerceModule.png
diff --git a/helix/principles/subsystems/commerce.rst → helix/principles/services/commerce.rst b/helix/principles/subsystems/commerce.rst → helix/principles/services/commerce.rst
@@ -2,7 +2,7 @@ Sitecore Experience Commerce
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 When working with Sitecore Experience Commerce, there are several
-more subsystems that you could end up posting code or config changes
+more services that you could end up posting code or config changes
 to. These include:
 
 - Sitecore Commerce Engine roles (Shops, Authoring, Ops, Minions)

diff --git a/helix/principles/services/index.rst b/helix/principles/services/index.rst
@@ -0,0 +1,21 @@
+Services
+-------------
+
+As Sitecore moves to a services-based architecture, there are
+more and more services being introduced that you could have to push
+code & configuration to. For example the Sitecore Experience Commerce 
+Engine Roles, the Commerce Business Tools, Identity Server and the 
+different XConnect instances.
+
+The most important thing to remember with these services is that
+you should still abide by the Common Closure Principal - classes 
+that change together are packaged together. This means that you 
+shouldn't, for example, group all of your Commerce functionality
+together as then you're reverting to grouping by Type instead of by
+Functionality.
+
+.. toctree::
+    :caption: Topics 
+    :titlesonly:
+
+    commerce
diff --git a/helix/principles/subsystems/index.rst b/helix/principles/subsystems/index.rst
diff --git a/helix/principles/visual-studio/structure.rst b/helix/principles/visual-studio/structure.rst
@@ -22,7 +22,7 @@ architecture of the specific customer implementation. Be aware that a
 Visual Studio Solution should logically group together conceptual
 modules – not VS projects – and therefore all Visual Studio projects
 belonging to a logical module should be managed together in one VS
-solution, regardless of how many subsystems it targets.
+solution, regardless of how many services it targets.
 
 .. admonition:: Habitat Example