Application layering and DataMapper

184 Views Asked by At

Hi I just read the book Patterns of Enterprise Application Architecture . They say about you should do enterprise applications in layers and that you are not supposed to make one layer use the above layer only the layer that is one down... Like domain layer can use DB layer but not vice-versa. Then there is a chapter about DataMappers that create Domain Objects. There I am a bit wondered why can he make a DataMapper in DB layer create an object in Domain Layer since it is not following the rule that the bottom doesnt call the upper. So my question is shouldn't be domain objects actually in DB layer , or what is a good way to make domain objects without making the DB layer use domain layer

3

There are 3 best solutions below

0
On

One approach to solve the problem you spotted would be to use a layer of abstraction between the domain objects and the database.

In a nutshell its dependency inversion / injection.

You define an interface the defines all the actions that a data provider can perform, you then build concrete data providers that implement the interface, and the business logic / domain layer talks to that. That way you're not tied to the database.

You can then build the data mapper in between the business logic / data objects and the interface (if you want to reuse it), or as part of the data access if it needs detail that is specific to the data provider.

0
On

I personally do not agree that domain-model is a layer same to other layers, because it does not contains any behaviors, it is just a domain related entity / data object.

That is to say, we can not make the conclusion that it is special only to Business Layer, if you use some ORM component, it is clear that Domain-Model is used direct in your Database Layer, because it is auto-mapped internally.

0
On

I think the problem here is that you make some assumptions about the Domain Model.
As per the book you mention a Data Mapper is really only required by a rich Domain Model, and in this case the best would be not to use entity beans as a Domain Model, but to use instead POJOs.

Now if you go this way, I'd argue that the Data Mapper and the Domain Model classes reside in the same layer, on top of the persistence layer (which is made out of DAOs and entities). The Data Mapper doesn't do any direct work with the database in this case.

If on the other hand, the Domain Model is based on entities, then I'd argue that it is also part of the persistence layer and the Data Mapper also fulfills the role of the DAO in this case, so again they are both (at least partially) in the same layer.

What's the best solution? As per the book I'd say it makes sense to use entities as Domain Model only in the very simple of the cases, go separate for anything complex (see Domain Model in Chapter 9 of that book)