Business-layer vs. model-layer

[Martin Kersten]

I would like to start a discussion about the business-layer and its relation within the model-layer.

There was once a time, I 've thought of seperating those, following the three tier architecture (Presentation, business, implementation), but this is wrong I guess.

Currently I think the business-layer includes the model-layer, making the model-layer a part of the business-layer.

The achitecture of my current project looks like this:

Model: 4 Hibernate persisted object classes

Plain Business: One CoreModel interface providing access to additional model-related operations, like to create new objects, to delete them (make them transient) or to perform some complex queries. It becomes an mediator for several daos and controls some advanced transaction managements.

Implementation-Layer: Hibernate related stuff (two classes, Spring hibernate support is just great)

Daos: Four Dao implementations (are they part of the business or the implementation layer?)

There is also another interface used for remote access of a complex client application. I also consider this to be part of the business-layer.


So the question remains: Are my thoughts ok?


Cheers,

Martin (Kersten)

[smccrory]

I prefer to keep the persistence tier / model layer separate from the business layer, both conceptually and practically through separate package, classes, interfaces and a clear separation of concerns. My main motivation for this is to keep persistence implementations decoupled from the business layer so that if I want to move away from Hibernate to SOAP, EJB or JMS calls for one or all of the data sources, I can do it without much work in the business layer.

I do realize that for many applications this is unnecessary overkill, and sometimes I grow into this separation by first creating a proof-of-concept without all those additional components and layers. However, where I work, our designs eventually have to go in front of an architecture review board and they appreciate the separation of layers to make it easier to scale the apps down the road (we're becoming very SOA-focused as a result of having to deal with lots of apps whose usefulness grew faster than their architecture). As always, it ultimately comes down to a conscious design decision, weighing the tradeoffs.
Scott

[Martin Kersten]

The model is also resisting in it's own package and it is not aware of the DAO implementations. So the package/modul dependency is like:


DAO <-- Business Interface ---> Model

But the question is, where to draw the line and call that thing Business-layer. That's bugging me for ages.

[smccrory]

I guess I don't understand. To me, the DAO layer is totally about implementation, whereas the business layer is about service-based aggregation.

Scott

[Martin Kersten]

The Dao satisfies the needs of the business logic. Sure it is an implementation detail but the requirements are imported from the business layer. So at least the specifications of a DAO are part of the business logic (interface belongs to client principle).

the DAO layer is totally about implementation, whereas the business layer is about service-based aggregation.

I guess you refer to the three tier achitecture (Presentation, business, implementation). There is also another architecture possibile: three layer architecture: Presentation layer, business aka domain-layer, data source layer.

Since I wouldn't like to talk about tiers - they have further requirements like chinese walls - I would like to talk about the three layer architecture.

I noticed that mearly every project I did, the model, dao and the rest of the domain logic is melting together (clearly seperated within packages of cause). The needs of the domain logic drives the model and the model drives the DAO (vise versa). I guess it is quite difficult to say, where to put new code.

[smccrory]

I think I understand what you're getting at, in that business requirements (usually submited in terms of visual and behavioral terms) have a direct influence on app design all the way down to the persistence layer. That's true, and any given layer is meaningless in this respect without its business context, so, you could argue that there is a blur in the distinction between them.

However, you need to remember where we used to be in terms of application design before layered architectures became popular. Without a clear and operable distinction between the layers, many applications in the past suffered greatly under convoluted and intertwined spaghetti code. I could reference a dozen in-house ASP/COM, PHP and Perl-CGI apps that are still maintained in my area today, and they're very difficult and expensive to work with. Furthermore, the move from one DB technology to another (from MS SQL to Oracle and DB2 in our case) will take a lot of work, and you can pretty much forget about web services for these apps without writing entirely new and segmented code.

If what you're observing is simply a facet of application construction, then I'll agree, but I'm sold on the idea of layers, both for actual code, but also for sharing a language and a common library of patterns we can use to achieve flexible, scalable apps.

But as always, your mileage may vary.

Scott

[diegum]

I give my point of view in another thread of "Architecture discussion"

http://forum.springframework.org/showthread.php?t=9675

In general terms, I agree with those who think that DAOs don't belong to business layer, although they are invoked surely from there

[Martin Kersten]

In general terms, I agree with those who think that DAOs don't belong to business layer, although they are invoked surely from there

I guess I have found the spot. Normally the DAO does not implement a given type (-requirement). Therefore there is no interface/abstract definition involved. Since the interface/abstract definition would belong to the client (business-layer) then you can say, the DAO requirements are part of the business layer and the implementation of the DAO (hibernate or what so ever) belongs to the database-layer (implementation tier).

But to make things clear: You are building a solution using more then one DAO implementation. So you will create something like a DAO interface/abstract type being part of the business layer. Then you will have a logic choosing, which certain DAO implementation has to be choosen. So the question is, is the logic choosing the DAO being part of the business-layer? What do you think?


For my oppinion, the business-layer does not 'contain' the DAO implemenation for sure. But the requirements about how the DAO looks like/ is used, belongs to the business-layer since the DAO is statisfying the needs raised by the business-layer. Maybe we should drop business-layer and refer to the term of domain-layer. So by using domain-layer it is clear, that the model-layer is part of the domain(-layer).

[Keith Donald]

How about just say your DAO interfaces define your persistence requirements? And your persistence requirements are driven by your business requirements, and are in direct support of those business requirements. Makes sense to me; as generally multiple persistence requirements (realized by DAO interface methods) are required to execute a single business transaction.