by Oren Ellenbogen | Design

Refactoring our architecture

After a long meeting with Ken and Roee about our(SQLink R&D department) architecture, I decided to put it out on the table – maybe you can give us some better insights about some questions we brought up during our session. I’ll start from the end of our session – this is the architecture design we thought about:


layers_small.jpg


Before I’ll start:

We’re generating our code (as much as we can anyway) which means we’re working in dual mode – “Data\ERD Driven” development for trivial data-access work and pure OOP development for our infrastructures\services. The generated code uses our infrastructures\services according to its needs, of course.
That was important to specify as some of our architecture decisions are made according to this development model.


So what’s the difference between this architecture and the one we had before ?
Old architecture:



  • The GUI (Graphic User Interface) talked only with the BL (Business Layer), even for data-operations which were NOT business (or logic, for that manner) at all.
  • The Business Layer was responsible to wrap any call to the Data Access Layer and publish any exception (if occurred).
  • The Business Layer was auto-generated but was “table based” instead of “context based”, i.e – there were directories for each generated table and in each directory – the relevant classes for wrapping the DAL(Data Access Layer) calls. This caused our Business layer to become a “Data Gateway” instead of clean business logic layer as it should have been.
  • The business layer was pretty massive – think about generating 80 tables. This means 80 directories in the BL project for 80 “Data Gateway” operations. Any real logic was hard to detect.

What we’ve changed:


  • It was crucial, for us, that the GUI will be “aware of” one layer only. The application shouldn’t “know” if the given data is logic based or not. Its only purpose is to present data, that’s it.
  • With this in mind, we wanted to make a clear separation of our “Data Gateway” and our “Business Logic” services. Application Gateway layer was born.
  • Application Gateway layer is now responsible for wrapping any calls to the DAL, BL or any other required services. In addition, it is responsible for publishing any kind of exception which occurred in any one of the underlying services (including DAL & BL). The directory structure is now:

    • ApplicationGateway.Data.[Table] -> under each of the tables there are the required classes for clean data operations (CRUD).
    • ApplicationGateway.Logic.[Context] -> the required classes for each logic context.

Open note:

With the new architecture in mind, we had some open notes which were answered but maybe could have been handled better.


The Application Gateway is now a manager\wrapper\sometimes facade class for our services and is responsible for communicating between the layers, is it completely true ?

A scenario:

The Business Layer needs some data in order to do some logic stuff. It makes sense that the Application Gateway will query the DAL and then will send the results for the BL method so it will be able to do the logic stuff with ease. But what happens if the BL method needs different data according to the inner logic.

Solutions:

1. We know the entire process of the BL method – so we can send all the data, even if some of it will not be used. BAD.
2. We can send delegate(s) to the BL method so the Application Gateway will be raised if any other data will be required. if so – the AG (Application Gateway) will be responsible for communicating with other services and return the required data back to the BL method. This is good decoupling but requires harder maintenance and development as the BL method could potentially required different delegates (signatures) – requires experienced programmers.
3. We can put a reference between our BL and the rest of the required services. In this case, if the BL method required data from the DB, we will add a reference to the DAL, create the required object and get the required data. This solution is easier for maintenance and development (requires less knowledge by the programmer) but create some coupling between the services.

Our decision:

We decided to go on solution #3 – better trade off.

 

What do you think ?

 

Oren Ellenbogen

 

4 thoughts on “Refactoring our architecture”

  1. I’ve read about your new architecture, it sounds to me a little bit like orchestration layer isn’t it?
    If not what the difference?

    I agree with your thinking about the difference between the BL and the DAL, and the growing files/directories.

    A smart person told me that you cannot always say standards! and you can sometimes call your DAL without going through the BL.
    the same I think about the Gateway it can call the DAL directly but there could be reason to do this from the BL.
    Just check that it won’t make security holes.
    so I agree with the third.

    BTW, I like the picture of the architecture.

  2. That’s exactly what it is – an orchestration layer.
    About the security check issue – I think that a security checks should be in the orchestration layer rather than in the business logic layer, so I would put it there in most of the cases; This will prevent any security holes due to a direct access to the DAL.

    There is a true power in decoupling the BL from the DAL as the BL can pull data from other services which it’s now(solution #3) aware of. This will allow me to change the logic process datasource (DAL\WebService\Whatever) without touching my business logic layer. But as I’ve mentioned – it’s quite hard to implement (in an easy way).

    About the picture – 10x! It took me 10 minutes via Adobe Photoshop ;-)

Comments are closed.