I have started working on ultimate ;) clarification of such terms like SOA, DDD, n-Tier, business entity, business layer, data access layer, persistence layer etc. and their place assignment in the enterprise applications' landscape... 

Look at first, early draft of graphic that I have called "Second Life of..."

And here a sample thought :) from my article:

The definition of a business entity is one o the most difficult things in the software architecture world. The problem that we have is this combination of words “business” and “entity”, the first depicts something very complicated and the second states for something simple – so we are trying to define something like “complicated-simplicity”…

I have taken in my hands this book once again, driven by the fact that since 1st of July I have joined a new team and a new project. After years of experience in software development area I have, no doubt, my own point of view on enterprise architecture. But in this post series I will try to comment and polemist with myself and the Author (well-know Author) on different themes he has touched in his book. The fist one is “business logic”.

In the book I have found these sentences:

“Then there’s the matter of what comes under the term ‘business logic’”. I find this a curious term because there are few things that are less logical than business logic.”

“A few thousand of these one-off special cases is what leads to the complex business ‘illogic’ that makes business software so difficult.”

Curious, in my opinion those “thousand of these one-off special cases” define very exactingly the business logic. Business logic without those special cases would be just “logic”, that we can find everywhere in our environment starting with remote control. But the main problem for most architect and developers is to understand that we are not tolerating any “acceptable uncertainty” like other areas do. Let’s take a simple example of a process of building a house. We are tolerating some uncertainty in a lot of cases, e.g. how windows are fitting into frames. It is ok, to have, just shooting, a one or two millimeters “uncertainty” between the window and the frame. It’s normal, and it’s even desired!

But the software development operates on “atom basis”; there is no place for exceptions or toleration. Everything has to be strictly specified, and the word “exception”, so normal in case of business logic, has for us, architects or developers a terrible meaning. We don’t tolerate exceptions and that’s our problem. And the main task for us is to familiarize ourselves with those exceptions, “special cases” or whatever and to shift from the idea of identifying it as “illogic” to usual “business logic”.

Cuxhaven, 18.07.2007

For my current project (an enterprise application for a well known big oil company) I have chosen the SOA approach as the base for the application architecture. At this moment I have to put emphasis on the word “application” architecture (SOA as Service Oriented Application supporting SOA as Service Oriented Architecture), thus a way of writing SOA enabled applications that leverage ideas of services not only for EAI purpose but also, and as the main approach, internally. The main problem about SOA in my opinion is the idea of some architects to define it as the way of integrating applications within enterprise and to completely forget about the architecture of those applications (not all of them are old legacy systems, some of them have to be re-written or re-designed - there is a big need for an application architecture that supports SOA).

So to leverage SOA I have decided to structure my application on business processes basis, not on development layers basis. In this way I have defined services for calculating, manipulating data etc. I was able to talk with the business guys using their language. Of course internally all my services use n-tier architecture with clear data and business layers, but as I said I was able to hide those “details” from the business guys. Secondly this approach made it possible to easily structure my development team. Due to the fact that SOA clearly defines the owner of the process and data, there ware no problems to set up developer groups on that “ownership basis”. So far, everything was brilliant…

The problem that I have faced was the ownership of business entities. For the data and business layers of services there is not such challenge, we can clearly define the owner. But the entities that are based on OO principles are much more complicated. Lets take an example of a customer entity, which has to be “combined” with a contract entity. I would expect to be able to have within the customer entity a collection that contains all contracts entities of this customer. In the other way I would expect that the contract entity would contain the information about customer entity… Both information (about customers and contracts) will than have to be loaded by two separate services (due to ownership assignment); lets say Customers Service and Contracts Service… And that is the breaking point. One of the main principles of SOA is the independence of services.

Ok, lets say we would build some kind of intermediary service to consolidate those both services, to be able to fill our customer or contract service. But this causes next big problem. The methods responsible for filling entities should always deliver, I would call it, a “full loaded” entity. It is a bad idea to do it partially and to leave the responsibility of assuring the deterministic way of filling entities on developers’ shoulders. It will be always error prone.

Next problem are additional services, which also have to combine “their” entities with the “foreign” entities from other services like, lets assume, Billing Service that would own a payment entity which should also contain the customer entity…

Yes I had a problem… The whole SOA was suddenly only a buzzword for me…

But wait for the second part: SOA vs. Business Entities Part 2/2 (The Peace)

As stated in one very good book about SOA, that I have read, we can define following service types:

As we can see, the most complex and frequent-changing type of service, which you should build if you want to fully leverage the SOA, is the process centric service. Truly saying since the beginning of SOA I had an architectural problem (or better: challenge) how to build this kind of service in the most effective way. Simply saying, what should be done is a kind of workflow engine with the ability to work in a stateful manner. It is not a trivial task. And one of the basic principles of building SOA based applications is … the simplicity. Do not overdesign! So I have always decided to not to extract the workflow into an independent service but integrating it into front-end component. Ok, I know, bad design but I had to be pragmatic and do my projects in time, budget, scope and quality…

But now we have the WF. Wow, I have followed the development of this library since early betas. It is unbelievable how easy you can build now a process-centric service of big complexity. A service that is really stateful and easy to change, a service where you are able to see and steer your processes. We have finally everything to build fully process-enabled SOA applications. Thanks Microsoft. Something big is about to happen…

This blog is dedicated for all my thoughts about building software in the most modern but also simple and pragmatic way… Hopefully I’ll find enough time to fill this blog with life…