Differentiating Between Business and Technical Components

Let's start with a couple of quick definitions.

Business components: They hold business values plainly written in a language like Java, JavaScript, etc.

Technical components: They hold technical capabilities, usually provided by the frameworks.

We, still are not completely aware of what technical components are. They are provided by both the technology, language (like servlets and JSP J2EE), frameworks (Angular, React, Spring), etc.

Servlets allows you to let your business be used over network, whereas SOAP and REST services allow you to share your business to be used by other software, which may be written in different technologies. So the core is your business component.

In Angular, your controller allows you write dynamic web pages and directives. That allows you to write your own custom tags or attributes, but as these are technical components, they should not contain anything business-related.

Business components are the technical representation of real business, like adding a todo to the list of todo, removing it from the list, updating it in the list, etc.

So, this is the real logic where we usually call business logic.

We know what technical components, are but we don’t know that they are less important than business component because they will be replaced with other, new technical components of other technology or frameworks in the future, assuming you have kept your business and technical components apart.

Here's a Servlet example where differentiation is not possible and the technical component holds all the business logic.

public class ToDoServlet extends HttpServlet {

    private ToDo toDo;
    private List < ToDo > toDoList;


    @Override
    public void init() throws ServletException {
        toDoClasseList = new ArrayList < ToDoClass > ();
    }

    @Override
    protected void doGet
        (HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {

        //Fetch the data from the request
        //create a list to keep todos
        //Put todo in the list
        //Do everything here.
    }

So, to write a good example, don’t think about writing Servlets, start with the solution to the problem.

Create a class that will represent ToDo.

Class ToDo {
    //All the properties representing a ToDo 
    // All the operation that can be performed on a ToDo like updating the todo etc.
}

Create a class that will represent the list of ToDo.

Class ToDos {
    //Properties representing a list of todo
    //Operation that can be performed on the list of ToDo like adding, deleting, updating
}

Now, writing test cases for the above business components is easier.

Create a servlet:

Class ToDoServlet extends HttpServlet {
    //Will receive the web request and delegate to the ToDos for the processing
}

Things You Should Consider

How separating technical and business components helps in migration in future:

So, if we start thinking about the solution of the problem without the framework, then we will be able to create good business components, which will be then be used by or wrapped within the technical components.

Why should you care about business and technical components?

Frameworks come and go, but businesses might remain for decades. With that in mind, business components should be given more importance than their technical counterparts.

Why do we focus more on how to make our technical components better, rather making business components better?

As mentioned, our business components have the real value, but the market asks for a knowledge of technology, frameworks, etc. Of course, technical components come and go, but business components will remain because they define business in technical terms. Still, the market wants a technical knowledge base, so that becomes the focus.

How will writing software based on business and technical components allow you to change or upgrade framework with minimal effort?

You just need to replace the frame with other new framework. For example, say you have your current application with Servlets and JSPs (technical components), which was written well by keeping business component (plain Java classes) separated with the technical components (Servlets and JSPs). Now, you have a requirement to migrate the application to Spring. Now, there is no need to write well-tested business logic again — you just need to pick all the business components and wrap them with the Spring technical components. This will save a lot of effort in development and testing because you already have tested business components, which will, in turn, save costs. 

How to write business components separate from technical components:

You, already know this, you just need to be more conscious while writing software. This is related to domain driven design (DDD) — that link comes with a code sample if you want to know more.