Sitecore helix pattern and where to place your business logic

Question

I've a new sitecore helix Solution and currently I am a bit unsure where I can place my business logic?

• currently I think I need to extract the business logic into some external services is that the "right" approach or do you host the business in your sitecore project?

Answer 1

First of; there is no single "Sitecore Project". There is your solution, and that's what Helix addresses.

As to where to place "business logic" - you use a generic term, when a specific one is required. Helix advocates breaking things down into logical groupings (modules). So if you were to say, develop some Newsletter functionality (as mentioned in another answer here) - that would logically group into a "Newsletter" feature.

This feature would (maybe) be a single project. Inside that you would have your view files, your controller renderings and so on. But you would also have your INewsletterService or whatever else information structure your newsletter is built upon.

It's also likely that, if not now then later, some of that newsletter functionality would be pushed down into the Foundation layer. Like the actual mechanics of sending a mail, for instance - which could have uses elsewhere in your solution. Like sending a registration confirmation mail or whatever it may be.

So you group related stuff together, that's (you know... simplified) what Helix is about.

Answer 2

I would say it all depends on the complexity of your domain. If the amount of business logic and 3-rd party integrations is low, it might be enough to keep the code in the appropriate Feature/Foundation module, as Mark has mentioned above.

However, if you have a complex domain (e.g you are building some enterprise-level project), where amount of bussiness logic is high, it is worth considering separating it to a separate microservice(s). In this case Sitecore will be responsible only for handling content (and analytics), while your Business API microservice(s) will handle all the business logic.

In comparison to hosting business logic within Sitecore, this approach has the following advantages:

• Scalability of application. API can be scaled independently from Sitecore instances. Moreover, since API is not hosted within Sitecore instance anymore, it would require much less hardware resources.
• Freedom of technology choice. You are not bound to Sitecore's framework dependencies, so you can easily build APIs on top of ASP.NET Core and even any other platforms/languages, like Node.JS
• Perfomance improvement. Sitecore adds some overhead to each HTTP request, which will not happen with separately hosted API.
• Scalability of a team. Developers working on business logic APIs do not need to know how Sitecore works anymore.

However, there is certainly a price to pay:

• Deployment of the APIs. You will have to setup a separate CI/CD pipeline for your APIs.
• Accessing Sitecore items. If your business logic needs to access data from Sitecore (e.g some implementations store some configuration in Sitecore items), you will probably need to move configuration away from Sitecore.
• Sitecore analytics integration. If you have a requirement to personalize your website based on data from your business domain, the implementation will be more complex.

Answer 3

Put your business logic into a Feature or Foundation layer of your solution. For example, if you have a business logic for your Website's Newsletter, then crate a Feature.Newsletter project and Foundation.Newsletter (if needed) and put your logic there. You can put all your services, views, controllers etc into feature project.

Answer 4

Definitely keep your business logic in feature projects. As previous answers gave you example with newsletter I will explain with same example.

You have newsletter part of your page. Create newsletter feature project and inside it put Models, Views, Controllers, Services, Repositories and everything related to it. I also like to put scripts and css files on feature level.

Places where you use foundation are some things that are common for everything let's say you implement some Mapper for mapping Sitecore items into Models. You will create for that Foundation.Mappers project and reference it from any feature project where you use it.