When you slice up your architecture into capabilities, you will also need to put the slices back together again in order to present an integrated app, or web user interface, to your users. When you take a look at a typical app or website, you'll quickly notice that it is composed of multiple parts that each logically belong to different business capabilities.
As a concrete example, here is the Amazon product page for one of my all time favorite books (a must read) where each of its parts is indicated by the capability it could belong to. As you can see some parts could belong to pricing, others to inventory, a couple to reviewing, etc...
Ideally you can tie your slices together as high up the technology stack as possible, preferably at the user interface level, so that as much code as possible is included into the slices. The composed parts should be delivered to the composer, by the different slices, without further need to write any additional logic in the app.
Web Components
On the web this approach is fairly easy to use as HTML 5 has a number of specifications specifically designed to achieve this goal. These specifications are collectively refered to as Web components. The most important specifications in this set are:
- Custom Elements: Which is a way to define your own HTML tags using javascript. This spec has full browser adoption for "Autonomous custom elements" since the beginning of 2019, which is the part you will want to use mainly.
- HTML templates: These are a method of declaring portions of reusable markup, which is parsed but not rendered until you clone it (typically in your custom element code). This spec has full browser support as far back as 2016.
- Shadow DOM: Which is a method of establishing and maintaining functional boundaries between DOM trees and how these trees interact with each other within a document. This allows elements to have a specific DOM tree and css of their own, independent of the rest of the page. This spec is still a working draft, but already has full browser support since 2019. I personally do not use it that often though and I would advise to use it with caution until it reaches the Living Standard state.
The main idea of using these specs for the purpose of slicing and composition, is that each of the business capabilities provides the code needed to implement specific HTML tags, e.g. <book-title></book-title> or <place-order></place-order>, etc... for all of the parts of information and behavior that it wishes to expose. These tags are then put on (static) html page and magic happens.
Distribute using a package manager
The code for these web components can be built stand alone and kept in the same code repositories as the other parts of the business capability. Once created and tested, they can be packaged and published using a package manager, and finally referenced as a dependency in other components or apps.
Personally I'm using the Yarn package manager to create my component packages. These packages get pushed to Github Packages for the private repositories that hold the capability code. Once published I can pull them in as dependencies in my apps, again using the Yarn package manager.
What would you like me to cover next?
The web components specification is very dependent on javascript which has natural implications on other aspects of an architecture such as view model composition, website hosting, protocols used to exchange data, etc... feel free to let me know in the comments what you would like me to cover in a future post.
