The Architect´s Napkin

Software Architecture on the Back of a Napkin
posts - 69 , comments - 229 , trackbacks - 0

My Links



Post Categories

Set the logic free

The main concern of software cells is how business logic is distributed. But as I write "business logic" I don´t really feel comfortable. The term sounds as if software cells were just a tool to help modelling business applications - as opposed to games or compilers or infrastructure. But right to the contrary: software cells claim to be a universal meta model for software. You can model any software with them. That´s why I don´t like to use the term "business logic". I prefer the neutral and unqualified term "logic".

So at the core of a software cell is logic code as opposed to technical or infrastructural code. If you like, qualify logic with "business" or "domain" or "application". But in the end it´s only important that the logic code, the core code is not concerned with technical details. It should not directly call, for example, a communication or persistence API. But more of this separation of concerns in another posting.

When thinking of logic, think of all that which is not dependent on a certain way of accessing this code or storing data or comunication with other software. Think of the invariant code that is independent of such "interface details" - whereas "interface" means interfacing with other software cells or infrastructure or resources or humans.


If you think of a prime calculation application, what would such invariant code be? Well, for example the prime calculation algorithm. You need it regardless of whether the primes are displayed on a web page or in a desktop client; you need it regardless of whether the primes are send to another program via TCP or stored in a flat file for later import into Excel.

Ok, so at the heart of the software cell concept is application logic. At the core of any software cell is logic code. It´s the code that solves the problem the whole application is about in the first place.

Now you might say, that´s not much different from what you have thought of N-tier business logic all along - and I can´t but agree.

However - and this to me is an important however -, the N-tier architectural model pretty much confines the logic to one OS process. If you´re talking about a 3-tier application you mean 3 OS processes with (all) the colorful (business) logic residing in the middle tier process:


That might have been ok in the mid 1990s. Back then distribution of code was not that easy with either socket or DCOM communication. And it seemed less often necessary than today. Client/Server architectures were the norm, N-tier architectures seemed to solve the scalability problem of internet applications, and that was pretty much it.

But today... today communication is much, much easier. Web services, .NET Remoting and Enterprise Services are simple to use RPC technologies. Even socket programming is no longer a black art with the System.IO and System.Net namespaces. And WCF is here to change the very paradigm of distributed communication by providing a neat unified message oriented API.

This in turn makes distribution easier. Setting up an application to consist of several very different "presentation tiers" and several "middle tiers" and several "backend tiers" all serving different purposes and maybe communicating in a P2P manner with other similar "tiers" is becoming the norm. That´s why I don´t see the term "tier" for an application´s OS process to fit anymore. For certain architectures it´s ok to use - but to let your modelling process be guided by it, seems limiting. Take off the "N-tier glasses"! And in terms of the pre-trans-fallacy enter the trans level: go beyond the slavish adherence to the N-tier "rule"! Set yourself free to think in different, more flexible terms. That´s what software cells are all about. Think cells instead of tiers.

What does that mean for your logic code? Well, it means, it should be able to move freely among the topology of an application. The meta model of software should allow logic to exist at any place an architect sees fit. That´s what software cells are about. They allow you to model OS process topologies and more to fit a problem and not a pattern. And they allow you to put logic in any place you like.

When you start a project, though, all application logic sits in one place: in the one and only all encompassing single software cell representing your entire solution:


This single logic core contains all the logic code your application needs - despite you not knowing what this code will look like in detail. You just take it as a black box, or a black box made up of several parts or aspects. Each being a different, (sooner or later) clearly distinguishable responsibility.

But that´s just the start. Sooner or later you´ll want to decompose the initial single software cell into 2 or 3 software cells. That means - to come back to the biological cell analogy - you cause a cell division. Whereas biological mitosis creates two clones, though, software cell division creates two or more software cells that look different. And that´s the whole point when distributing logic in this manner: the logic in the original cell should be split up. Parts of it go into one of the "child cells", other parts go into other "child cells".


image image  image image


The reverse is also possible: you might look at a software cell diagram and decide to merge software cells into one. Either physically, i.e. reduce the number of OS processes by aggregating logic from two or more processes in just one. Or logically by wrapping software cells in a software cell on a higher level of abstraction. This happens most often when you try to depict legacy systems with software cell diagrams. There already exist several OS processes and you need to describe the status-quo in a more coarse grained way to management.

Decomposition and aggregation might be the most common operations on software cells and their logic cores. But there´s yet another transformation you can apply: you can of course move logic from one software cell to another.


Although this might sound and look a bit abstract to you right now, I assure you, it has great practical value. This value lies in eliminating any cognitive dissonance stemming from conflicts when trying to find the right place for business logic according to the canonical N-tier architecture pattern. This value lies in freeing your thinking about architecture. The pain when trying to fit your solution to the N-tier model might seem weak - but I argue, it´s there and it´s not weak, but only subdued or even denied. So once you look for it in yourself or your peers, you´ll realize its prevalence.

I´m not against layers as a pattern. They have their place and I´ll talk about them in due course. But layers and tiers as other patterns should not be the starting point of your thinking. Or at least, don´t believe them to be the ultimative truth.

If you want to use layers, use them as a structuring pattern for something. Don´t just draw layered boxes. Rather plan a structure and then (!) arrange it in layers. See layers/tiers as superimpositions over an architecture, but not as the architecture itself or its goal:


The stuff to arrange, the structural elements , that´s software cells with their logic. They are the material to build architectures from in the large. Why? Because they give you maximum freedom in arranging the most important part of any software: the logic.

Print | posted on Tuesday, June 17, 2008 7:32 PM |


No comments posted yet.
Post A Comment

Powered by: