SharePoint Site Structuring: Wide vs Deep (Part II)

In my last post, I presented a SharePoint site classification & structuring scheme for realizing the information architecture (IA) structural design of your information space to facilitate content organization. SharePoint has five main content containers that can be combined to best structure the content according to your IA:

• Root site collection: container for portal, home sites
• Explicit site collection: container for department, services, regional sites
• Wildcard site collection: container for team, community, project sites
• Top-level site (site home): container for content and subsites and channels
• Subsite (site section): container for content and even more subsites and channels

Sites always belong to one site-collection. A site-collection is just that, a collection of sites. A site-collection contains one top-level site (TLS), that again can contain a hierarchy of subsites. Hence site-collection.

Structures of top-level sites and subsites are generally labeled as wide or deep. A wide site structure uses multiple TLS sites (and hence multiple site-collections), while a deep site structure rather uses a single TLS site with multiple subsites with even more subsites. See the SharePoint site classification & structuring post for more details on this and the above five containers.

However, not all combinations are viable due to SharePoint software boundaries for the containers. This especially applies to how to combine managed site-collections with wide and deep site structures. As outlined in my last post, each major category gives a recommendation on the usage of wide and deep site structures based on the site classification. The recommendation on how to combine wide/deep with explicit/wildcard site collections is shown here (click to enlarge):

As you can see, it is not recommended to combine explicit site-collections with a wide site structure due to the limited set of explicit site-collections per SharePoint web-application. Using wildcard site-collections give the most flexibility as there is almost no limit on the number of site structures wildcard can hold. If you need a new top-level site, just create a new site-collection.

The SharePoint software boundaries on site structures per web-application is shown here (click to enlarge):

Each SharePoint web-application can hold about 20 explicit site-collections and about 50000 wildcard site-collections. About, as these boundaries are not hard limits - but performance will suffer significantly should your site structure push beyond them. The recommended limits on subsite structures is about 125 second level subsites under a top-level site, each with about 2000 third level subsites, for a theoretical maximum of 250000 subsites per site collection. Theoretical, as the maximum recommended database size per site-collection is 100GB and with hundred thousand subsites there will be little room for content in each subsite.

Note that root or explicit site-collection storage cannot be scaled as you cannot add another content database to a site collection. If scalable storage is a requirement, using wildcard site-collections is best practice.

Respect the SharePoint boundaries, and I recommend your never get close to pushing them. I once broke these recommendations myself for a wide site structure; a couple of years later the "client site" solution started behaving erroneously (mainly timeouts) because of more than 60000 clients being provisioned by then, pushing the 50000 TLS limit. The next time I designed a site structure to hold a million client sites, we did a proper information architecture LATCH (Location, Alphabet, Time, Category, Hierarchy) analysis. This resulted in a deep+wide site structure with the one million subsites (deep) hierarchically distributed based on the 9-digit customer number, across multiple site-collections (wide).

Steve Goodyear's decision diagram in the Determining Between SharePoint Site Collections and Sub-Sites post shows other important technical aspects when deciding between wide and deep.

Classification and Structuring of SharePoint Sites (Part I)

As part of my work as a SharePoint architect, I almost always run into poorly designed and structured SharePoint solutions. Mostly because consultants hardly ever seems to read and really understand the Technet SharePoint Site Structure Planning and the SharePoint Logical Design and Architecture guidelines or do any information architecture (IA) analysis. What is needed is a site classification scheme based on solution domains, usage, management and governance as shown in this article with structuring guidelines for each site category.

This post and the next is targeted at a technical audience; if back-end architecture details is not for you, jump straight to part III for a simple five step process aimed at business users, analysts and information architects.

IA defines the structural design of your information space to facilitate content organization, realized in a SharePoint site structure to store and manage your content. Skipping the IA and site structure planning will work for some time, perhaps forever, but eventually most SharePoint solutions grows into the software boundaries of the platform. The effect will be poor performance and frustrating user experience due to the unmanageable number of sites popping up everywhere.

SharePoint supports a flexible IA structure by providing several types of content containers, and you really need to understand how to use them:

• Root site collection: container for portal, home sites
• Explicit site collection: container for department, services, regional sites
• Wildcard site collection: container for team, community, project sites
• Top-level site (site home): container for content and subsites and channels
• Subsite (site section): container for content and even more subsites and channels

Note that it is a best practice to not use the terms "site" or "web" when classifying and structuring sites. Experience shows that these terms are so overloaded that is just causes confusion. Even the latest SharePoint guidance makes a classical MSDN mess using the term "root site" in some parts when referring to top-level sites. Also stay away from using site-definition names such as team-sites and workspaces.

In addition, I use "managed site-collection" instead of the term "managed path" to get consistent naming in my site taxonomy. Managed paths are central when constructing your URL space, but thats a secondary goal and only important as part of your IA structural design to facilitate content organization and driving findability. It is the site-collections held at managed path explicit and wildcard inclusion URLs that is the primary goal, plus of course that held at the root path.

It is important that you look at your diverse set of information and develop a classification scheme for the content that will go into your SharePoint solution. Develop a classification of sites and follow the planning guidelines on how to structure your sites according to SharePoint recommended practices. I like to classify sites into four major categories as shown here (click to enlarge):

Sites are classified into the four major categories based on the management policies (corporate to community, controlled to uncontrolled) and the life-cycle policies (predefined and planned, predictable and ad-hoc) of the site content. The four categories are numbered 1 to 4 ranging from most specific to very generic classification of sites.

Sites always belong to one site-collection. A site-collection is just that, a collection of sites. A site-collection contains one top-level site, that again can contain a hierarchy of subsites. Hence site-collection. As there is a limited set of explicit site-collections per SharePoint web-application, these should be reserved for a planned, wellknown small number of predefined sites. Use wildcard site-collections when the predictable number of sites is too large for explicit, and for ad-hoc sites that come and go in unknown numbers. Finally, there can be only one root site-collection per SharePoint web-application.

The following figure applies the SharePoint site structure design limits to my site classification scheme:

The major categories provide a recommendation of the type of site-collection to use; and for each category and site-collection type, the site classification scheme provides a recommendation for how to use top-level sites (TLS) and subsites to provide the structural IA design. There are two major ways to structure content within a site-collection: wide and deep. A wide site structure uses multiple TLS sites (and hence multiple site-collections), while a deep site structure rather uses a single TLS site with multiple subsites with even more subsites. Both approaches can be combined to best structure the content according to your IA.

Using a wide site structure is applicable for sites like projects and team-sites, as this gives the best control over site configuration, administration and management in SharePoint. Each TLS is a separate site-collection, and each site-collection is a management boundary for users and groups, access control, content taxonomy, navigation, branding, SLA, all in all sites are separated from each other and each have their own life-cycle and governance policies.

Using a deep site structure is applicable for sites like portals, departmental or regional content, and shared communities. All subsites with the TLS site-collection share the same navigation and content taxonomy, the same members and groups, the same branding, all in all the same configuration and administration and the same governing policies and life-cycles.

You will of course also need to consider the site-definition type that you plan to apply to each site, as this will influence what should be structured together to create a well planned user experience. E.g. within a internet "Publishing portal" TLS you would most likely not add a "Team-site" subsite.

Note that root or explicit site-collection storage cannot be scaled as you cannot add another content database to a site collection. If scalable storage is a requirement, using wildcard site-collections is best practice.

I recommend making a SharePoint site diagram like this to vizualize how your site structure is built by combining root, explicit and wildcard site-collections (click to enlarge):

I hope this site classification scheme will help you understand how to plan and design your next SharePoint site structure. At least it should make planning workshops more focused and less confusing, both for you and your customers.

Read part II for more details on wide vs deep site structures, including SharePoint system boundaries.

Read part III Five Steps to Structure Your SharePoint Sites if you're unsure of where to start your site classification and structuring efforts.

Puzzlepart - Exciting Times Ahead

Today was my last day as an MSFT FTE, tomorrow I'm co-founder and partner at Puzzlepart - as the second person in the company after my old colleague Mads Nissen.

At Puzzlepart we will continue our joint SharePoint adventure. Together we have delivered quite a few SharePoint and MSCRM solutions, such as this case study shown by Steve Ballmer himself at the 2005 business summit. As you can see from the video, we focus on delivering business value - and we're working on our design skills.

As they say at my old employer: I'm super excited to be here! And to my now former colleagues at MCS: Thank you for all that you do!

DDD Lessons Learned: CQRS, Fat Domain Model, Concrete Aggregate Entity

It's been five years since Eric Evans' classic book Domain-driven design: tackling complexity in the heart of software was published. Last week two interesting articles came out; What I've learned about DDD since the book by Eric himself and Domain Models: Employing the Domain Model Pattern by Udi Dahan. They both talk of lessons learnt about some of the concepts of domain-driven design (DDD).

Udi talks about a very common misconception about domain Entity objects, what I like to call the Fat Domain Model: using the persistent object model as the Domain Model. I've done this myself for many years, trying to avoid Martin Fowler's Anemic Domain Model and Fat Service Layer anti-patterns by adding the domain entity's behavior to the related data entity object.

Microsoft does a variant of the Fat Service Layer in their Three-Layered Services Application guidance: they use anemic Business Entity objects and keeps the business logic in separate Business Component objects, exposed by Service Interface objects. So coming from this, it seemed natural to merge the entity and logic into one when I started practicing DDD.

The description of the Entity pattern from Eric's book is clear on what goes into the entity object:

"It is natural to think about the attributes when modeling an object, and it is quite important to think about its behavior. [...] strip the Entity object's definition down to the most intrinsic characteristics [...]. Add only behavior that is essential to the [domain] concept and attributes that are required by that behavior."

So, only the data that is required by the domain logic should be in the domain object. Eric use the term "information about the business situation" in the book when explaining the Domain Layer, another hint that this is not traditional data entities. Querying and viewing entities is not domain logic, so there is no need to add all attributes of the ORM data entities used in the presentation layer to the DDD Entity object. Querying and viewing entities belongs to the Service Layer. I suggest using two separate object models (Command and Query Responsibility Segregation, CQRS) as shown in Udi's article, but think twice before implementing your forms-over-data application using the Domain Model pattern.

In his QCon 2009 presentation, Eric talks about the DDD Aggregate pattern and how it can be hard to model an Aggregate Boundary and decide to which Entity object a specific behavior belongs. Here is the definition of Aggregate from the book:

"First we need an abstraction for encapsulating references within the [domain] model. An Aggregate is a cluster of associated [domain] objects that we treat as a unit for the purpose of [ensuring consistency of] data changes. Each Aggregate has a root and a boundary. The root is a single, specific Entity contained in the Aggregate."

I think the Aggregate pattern is easy to misunderstand as it focuses on modeling the relationships and boundary of the root and its associated collection of domain objects - immediately making people think of the classical "purchase order with items collection" OO data encapsulation design or even ER-design. In addition, the strong focus the Aggregate being an abstract consistency mechanism leads to the misconception that Aggregate domain logic must belong to the root Entity object and that logic that involves associated Aggregate data will require that data to be modeled into the collection of domain objects.

Eric uses the example of calculating the weight of a grape cluster Aggregate. This logic doesn't belong on the grape Entity, so the only place to put this is on the stem Entity - because the Aggregate itself is not an object, just an abstract concept. He also talks about how this kind of logic typically is designed as an iteration of the associated object collection, while lessons learnt has shown that this OO legacy mindset is not mandated by the domain business rules. Udi also touches the same problem in the "UnpaidOrdersAmount" example in his domain model article.

The fact is that the domain aggregate is not just an abstract concept, it should be modeled as what I like to call a Concrete Aggregate. This alleviates the root Entity from getting responsibilities that doesn't naturally belong to it. This kind of non-entity domain logic goes into the Concrete Aggregate as its behavior and prevents leaking domain logic into the Service Layer.

Using Concrete Aggregate objects might also lessen the need for fully modeling objects within Aggregate boundaries. E.g. having a GrapeCluster object that can calculate its weight directly without loading a Stem and its collection of Grape objects makes the domain model much simpler. Again note the focus on business rules behavior rather than OO entity-relationship modeling.

I admit struggling with naming the Concrete Aggregate pattern, maybe Aggregate Entity would be a more self-explanatory name.