...
So a building block is a package of functionality with well defined boundaries and with access to their functionality restricted to the interfaces that they implement. So should you ever access the functionality of a building block directly without going through its interface. The answer is NO. All access is always through a predefined set of interfaces.
Let's look a few at more softer examples. The HR department in the company that you work for, holds information about you. You want to know what information they hold about you. So which off the following is allowable behaviour, in actual fact which one off the following give gives you access to that information
...
Version 2 off course. The HR department has set of protocols that you must follow, and that set of protocols represent the interface to the HR department. So we can clearly see from this example that the HR department is a building block with a clear set of interfaces i.e. the protocols.
...
In this example we have a specification (the ABB) for a web server. If the ABB is written in a clear and concise manner, it should be possible to identify any number of possible web servers on the market that will meet the ABB. In our example we have an ABB specification for a web server and there are a number of available SBBs (Apache web server, MS IIS, tomcat webserver etc).
But what about the following SBB examples
All of these SBBs do Both SBBs (JBOSS and Glassfish) have web server functionality, but they also have a lot more functionality. In actual fact, they have the functionality of a web serversserver, application serversserver, and messaging brokersbroker. Surely these extra bits are distinct pieces of functionality that could and should be described using specific ABBs? So are these SBBs really implementations of several ABBs or are they composite SBBs (in other words are these SBBs really several SBBs bundled together under a single composite SBBs which acts as a facade to them)? The SBBs are the latter. Essentially the SBBs such jboss and glassfish are in actual fact composite/aggregate components exposing other components through well defined interfaces. Each of these sub-components have their own associated ABBs. So the model really looks like this
...