According to Uncle Bob, the entity layer should know nothing about the database.
What about the JPA annotations then? Don't they violate the architecture proposed by the author? If they do, how to use the entities with JPA?
In a non-ORM world, a clean architecture would (or could) involve having DAO interfaces, with DAO implementations knowing how to retrieve the data from a database (or any other source), and convert and return it as a domain object. An upper layer would then use the DAOs (through the interfaces) to retrieve those objects.
This would allow you to for example create different DAO implementations for different databases, and you could change databases without bothering the rest of the software.
In a JPA/ORM world you can bypass a lot of that if you choose. You can use entity classes as domain objects, create the entity classes in a database agnostic way (i.e. not using any database specific NativeQueries for example). Now that your entities are database agnostic, you can just use NamedQueries in your service layer instead of creating DAOs.
In the end you need to have some layer which knows about the database, but in JPA's case it doesn't even hold true. Your entities are Java objects and it's the JPA implementation layer that is responsible for converting them to and from the database.
In conclusion: there are very few universal truths in software development and you can talk to a dozen uncles and hear a dozen versions of essentially the same "story".
Related
I have three tables on a database, and one old and good query that joins the interesting columns for the usecase on a DTO object after use a RowMapper. Classical Java approach.
But I am wondering, how can I convert this into a DDD implementation? How can I use entities for solve the problem without having 3 separated queries to create the models with it's fields, and then create a DTO just for create the object with the desired columns?
What I am missing? Or should be better the already implemented way?
You cannot convert that model to DDD.
DDD is about creating a business model in a separate layer: the domain layer. The purpose of this layer is to verify that any state-changing operations does not violate your business rules. How you model your domain entities must be driven by the use case you are handling, not how the data is stored: the domain layer is said to be persistence agnostic. It doesn't matter whether the data is stored in one or multiple stores, RDBMS, nosql, files, etc ... that's ther purpose of the infrastructure layer.
Domain object are read by a class called a repository. The repository behaves like an in memory collection of domain object, but actually re-hydrates objects from the persistence store(s). It operates as a mediator between your persistence model and your domain model. Since models may differ, the repository can flatten relations, join data from different sources, and ignore some columns if needed.
When querying your state, you don't need to use the domain layer at all. The purpose of that layer is to validate state-changing operation, business-wise, but this is unnecessary when querying the state. In that situation, you can implement classes, called mediators, that will query your database and produce presentation layer DTO. Like the repositories, mediators are adapters between your persistence model and your presentation model. It can join data from multiple persistence stores, flatten relations, and ignore columns as well.
Whether to use an ORM, or not, for accessing the database, is an implementation detail of your infrastructure layer. It has nothing to do with domain modeling, which is about your use cases and business rules validation.
In our project we use classes generated by eclipse hibernate plugin for persistence.
The generated classes have following structure.
MyClass extends BaseMyClass //POJO's, that are refenced in the hbm
files
MyClassDAO extends BaseMyClassDAO //DAO objects that use hibernate
session objects to provide CRUD API's for working with DB
My question is, would it violate Uncle Bobs clean architecture if we use the POJO classes used in the mapping files as the Entities in the innermost layer.
The hibernate specific DAO classes would belong in this case to the outermost layer and UseCases layer would communicate with this layer via providing an interface to be implemented.
Uncle Bob comments on this during a lecture in Norway while presenting this slide:
Uncle Bob says:
There is no Hibernate above the line. If you are using Hibernate it goes below the line. The application does not know that you are using that framework. It goes below the line. And Hibernate is a lovely tool. It's very good for gathering data out of the database and turning it into data structures. Very nice! But you don't want your application to know that you are using it. You put all that stuff below the line.
Robert C Martin - Clean Architecture, NDC 2012 (53:53 - 54:18)
Thus if you are using Hibernate annotations on the entities, you mix your domain objects with details of the database layer.
Some developers argue that annotations are not so strong dependencies, because if they are not available at runtime they just do not exist. That's true, but you also have to consider other principles.
If you put Hibernate annotations on your entities, the entity classes now have two different reasons to change: the domain logic and the database mapping.
This is a violation of the single responsibility principle. Therefore database mappings will affect your domain objects.
I guess there is a lot of confusion, because of the overloaded term entity. When Uncle Bob talks about entities he means domain. In Hibernate entity means database record.
That's why I usually distinguish them by using the term "domain entity" or "database entity".
I'm new to ORM and hibernate.
my application is of complex design pattern. with builders, fluent interface.
and those objects also throws exceptions while creating illieagel objects. and I use orm mapping to access database. I convert those ORM entities to my complex objects and vise versa. is it good idea or any other alternate.
As a general rule, you should create business objects (in your case they exist already) when you truly need them. So, if your application needs those complex objects, that is fine (but keep in mind that they are hard to maintain as you will have to change a bunch of objects when you make a change in your database and Hibernate objects).
If you could get rid of those complex objects, you could use Hibernate's detached entities as simple DTOs all over your application and you won't have the difficulty of maintaining two sets of objects. On the other hand, using business objects can make your web layer (or other layers) independent of Hibernate and its entities, so makes your life easier if somehow in the future you decide not to use Hibernate. From my experience, if the recent is not your case and you are thinking of Hibernate as a long term solution, using Hibernate's detached entities is a much easier solution.
Do you have some requirements which says that you need two kind of entities: those rich/complex and those ORM based?
I used ORM along with domain driven design and it worked fine. We decoupled rich entities (and value objects) from services and those entities were persisted from aggregate downwards.
You certainly must slightly change those entities when you want to use hibernate mapping but I haven't find anything which would break our DDD model. E.g. parameterless constructor can be private etc.
As we used fluent/xml mapping, model was completely separated from persistence layer, see term persistence ignorance
I am trying to rewrite a bunch of DAOs here is the setting:
only plain JDBC (no JPA, ORM whatsoever)
no interfaces used
lots of checks before inserting an object
Business objects are strongly linked
My main question is:
How do I persist/retrieve a business object that is composed of multiple other objects?
e.g. does my CustomerDAO know the AddressDAO and retrieve the csutomers adresses from there?
only plain JDBC (no JPA, ORM whatsoever)
Business objects are strongly linked
Not sure why you don't want to use JPA while you want your business objects to be linked, but at least you should use Spring JDBC template that would relieve you from some boilerplate code.
Regarding the other constraints, I would do it as follows:
I would still employ interfaces to define the DAO methods and implement them in a Spring JDBC template backed DAOImpl. Use the DAO everywhere and inject the DAOImpl.
My DAOs will be simply one-to-one mapping to the underlying tables and each DAO wouldn't know about the existence of other DAOs.
My Manager layer will have all the business logic that runs validation checks and prepares the set of objects that need to be persisted, calls the appropriate DAO and appropriate method (CREATE/UPDATE/DELETE) to persist the objects.
Again, the Manager layer will follow the interface-based implementation and the view layer would have manager types injected with the ManagerImpls.
My two cents!
You may Consider Using JOOQ. It is not JPA, but it may easily be used as an alternative solution. It is lightweight enough. It also provides provides a reverse engineer tool, where it builds your Database entities as DAO objects.
I have embed JOOQ in a relevant situation, where the application was fairly engineered designed. I didn't use its DAO functionality, rather than using it as a higher layer to avoid messing with JDBC Layer.
Cheers!
Composite entities are a layer above DAO's. If you want to remove ALL coupling, domain objects persisted by DAOs should be flat without relationships. See Core J2EE patterns CompositeEntity.
Also, it's a good idea not to introduce coupling inbetween the DAO's by putting finders for one in the other. E.g.:
AddressDAO.findForCustomerId(id);
is inferior to using a third DAO to manage the relationship. I.E:
CustomerAddressRelDAO.findAddressForCustomer(id);
If you use a relationship DAO neither address nor customer are dependent on (or aware of) each other.
I'm hesitating between two designs of a database project using Hibernate.
Design #1.
(1) Create a general data provider interface, including a set of DAO interfaces and general data container classes. It hides the underneath implementation. A data provider implementation could access data in database, or an XML file, or a service, or something else. The user of a data provider does not to know about it.
(2) Create a database library with Hibernate. This library implements the data provider interface in (1).
The bad thing about Design #1 is that in order to hide the implementation details, I need to create two sets of data container classes. One in the general data provider interface - let's call them DPI-Objects, the other set is used in the database library, exclusively for entity/attribute mapping in Hibernate - let's call them H-Objects. In the DAO implementation, I need to read data from database to create H-Objects (via Hibernate) and then convert H-Objects into DPI-Objects.
Design #2.
Do not create a general data provider interface. Expose H-Objects directly to components that use the database lib. So the user of the database library needs to be aware of Hibernate.
I like design #1 more, but I don't want to create two sets of data container classes. Is that the right way to hide H-Objects and other Hibernate implementation details from the user who uses the database-based data provider?
Are there any drawbacks of Design #2? I will not implement other data provider in the new future, so should I just forget about the data provider interface and use Design #2?
What do you think about this? Thanks for your time!
Hibernate Domain objects are simple POJO so you won't have to create separate DPI-objects, H-Object themselves can be used directly. In DAO you can control whether they come from hibernate or anything else.
I highly recommend reading Chapter 4 "Hitting the database" of Spring in Action, 3rd edition, even if you aren't using Spring in your application. Although my second recommendation would be to use Spring :-)
The DAO pattern is a great way to keep database and ORM logic isolated in the DAO implementation, and you only need one set of entity objects. You can make that happen without Spring, it just takes more work managing your sessions and transactions.
If I understand your post, this is sort of a middle-ground between Design 1 and Design 2. The H-Objects (the entities that Hibernates loads and persists) don't need any Hibernate specific code in them at all. That makes them perfectly acceptable to be used as your DPI-Objects.
I've had arguments with folks in the past who complain that the use of JPA or Hibernate Annotations exposes Hibernate specifics through the DAO interface. I personally take a more pragmatic view, since annotations are just metadata, and don't directly affect the operation of your entity classes.
If you do feel that the annotations expose too much, then you can go old school and use Hibernate Mappings instead. Then your H-Objects are 100% Hibernate free :-)
I recommend design #2. Simply construct domain objects, and let hibernate look after them. Don't write separate classes that are persisted.
Hibernate tries to hide most of the persistence business from you. You may need to add a few small annotations to your entities to help it along. But certainly don't make separate classes.
You may need some very small DAO classes. For example, if you have a Person entity, it would be fairly common practice to have a PersonDAO object that saves a person. Having said that, the code inside the DAO will be very simple, so for a really small project, it may not be worth it. For a large project, it's probably worth keeping your persistence code separate from your business logic, in case you want to use a different persistence technology later.