If I'm developing a hiberante application, am I also developing a DD model?
My application does have a service layer ( which is in lines with the Observer pattern). Will there also be a Domain Layer wherein all the hibernate entities exist?
I'm looking my application somehting like this:
Do I need to know Domain Driven Design to write Hibernate Entities?
Can the application be hybrid - OOD in the service layer and DDD in the persistence layer?
I'm confused. Please clarify.
If I'm developing an Hibernate application, am I also developing a DD model?
When using Hibernate, you'll probably create a domain model of entities and do some domain modeling but you aren't necessarily following Domain-Driven Design principles, there is no direct implication. And actually, I'm tempted to say that it's most often the contrary, most Hibernate applications end up having an anemic domain model.
Do I need to know Domain Driven Design to write Hibernate Entities?
No. there is no particular knowledge to have to write Entities. However, if you want to follow DDD, you obviously need to have some knowledge of DDD. And if you want to go this direction, using Hibernate (as your factory for entities) has some implications on the implementation. Domain-Driven Design with Spring and Hibernate is a very nice blog post on the topic and describes an AOP based approach.
Resources
The official Domain-Driven Design Community website
The Domain-Driven Design yahoo group
Domain-Driven Design Quickly (great summary book of Eric Evans's reference book).
Chris Richardson's aop-ood sample application
See also
Still confused about repositories
actually DDD is an approach and is not tied to the tools that you are using.
you can use Hibernate or any other OR mappers to do DDD or any other aspects that you thins is suitable for your case.
read more about DDD:
http://en.wikipedia.org/wiki/Domain-driven_design
Related
JHipster is great. It, however, models all objects as domain entity objects. An enum class, for example, is treated as a domain class. If I want to practice the domain driven design, I need to convert some of entity classes, which are generated by JHipster, to value classes along with other types of changes such as replacing primitive types with domain object data types. Can I still run import-jdl after making such changes? In the other words, whether the changes are maintiable with a JDL?
BTW, there is a good talk on DDD by Edson Yanaga posted on youtube.
An interesting talk about DDD:
Implementing DDD with the Spring Ecosystem by Michael Plöd # Spring I/O 2018
There's a concept coming from the video, that I've found very important:
JPA entities are not domain entities.
JPA entities and repositories are what you use to persist data on the Db. While the Domain is what you use inside the application.
To answer, I think that you can build your domain classes separately, without caring too much about JPA entities. I suppose that's better to have a consolidated JPA layer before to start building the Domain side, if the two are somehow linked (and usually they are)
Please consider that I've just started to study this topic. Would be good to hear other opinions.
It's a pity that, in short, JHipster just does not support Value Objects, which makes it incomplete to design a DDD application by only caring about models.
See
issue1,issue2,another SO question
I am learning Spring Data JPA, and I came across the term "JPA repository" (to be specific Spring Data JPA repository). I want to understand if the term "JPA repository" is a general concept (like JPA - a standard specification) or coined by Spring Data project?
What exactly does "repository" in this context means?
What exactly does "repository" in this context means?
Repository is one of the patterns introduced in Patterns of Enterprise Application Architecture (Martin Fowler, 2002). In the book, Repository defined as:
Mediates between the domain and data mapping layers using a
collection-like interface for accessing domain objects
A system with a complex domain model often benefits from a layer, such as the one provided by Data Mapper, that isolates domain
objects from details of the database access code. In such systems it
can be worthwhile to build another layer of abstraction over the
mapping layer where query construction code is concentrated. This
becomes more important when there are a large number of domain classes
or heavy querying. In these cases particularly, adding this layer
helps minimize duplicate query logic.
A Repository mediates between the domain and data mapping layers,
acting like an in-memory domain object collection. Client objects
construct query specifications declaratively and submit them to
Repository for satisfaction. Objects can be added to and removed from
the Repository, as they can from a simple collection of objects, and
the mapping code encapsulated by the Repository will carry out the
appropriate operations behind the scenes. Conceptually, a Repository
encapsulates the set of objects persisted in a data store and the
operations performed over them, providing a more object-oriented view
of the persistence layer. Repository also supports the objective of
achieving a clean separation and one-way dependency between the domain
and data mapping layers.
Further Reading
For more detailed discussion about Repository pattern, you should take a look at Patterns of Enterprise Application Architecture (Fowler, 2002) and Domain Driven Design (Evans, 2003).
My team decided to try DDD approach in new app we're developing now.
One of the obstacles that we face is our platform - we are forced to use ActiveObjects ORM framework (https://developer.atlassian.com/display/DOCS/Getting+Started+with+Active+Objects).
Given that DDD is huge topic by itself, existence of such a constraint makes things more complex. The main problem is propagation of changes of Domain Model entity attributes to the persistence storage via ActiveObjects. Are there any good solutions we can consider?
ORM is a persistence detail i.e totally unrelated to the Domain (different layers). DDD is not a huge topic. It's a simple mindset, tricky to understand and very skill dependent to implement (it's not a "how to" methodology).
DDD uses Repositories for everything persistence related. The Domain only sees the repositories (abstractions only), never the db, orm etc. The ORM is used by the repository. A properly encapsulated domain object might not be easily mappable to an ORM and you'll need different approaches for those cases (the memento pattern is a clean but expensive - boring - to maintain solution). But the essence is that Domain doesn't know about ORM and the Repository is responsible for persisting/retrieving domain objects (using the ORM).
You should also employ CQRS, you don't want your business objects designed for UI or reporting queries.
We started writing a Java Framework for our company. But we don't have enough experience about Java. We decided to use JPA framework for database CRUD operations.
What do you suggest about that:
about defining persistence.xml. We search creating dynamic
EntityManager and found some documents but we don't know that is
it best way.
Is it a good way that create a layer over JPA base db operations?
(for example CRUD methods.)
How can we do calling JPA CRUD methods from my CRUD methods in
framework?
We will use this framework for desktop and web applications. Is
deployment a problem for us.
Do we have to use EJB?
Is there alternative to JPA which you suggest? (example: ADF,JDBC)
Thanks
It highly depends on your requirements and what you want to do with your "framework". I do not know enough of your project to give you a real advise, but here are some thoughts:
What do you mean with "framework"? Are you developing a library which other people should use? What should be the purpose of your framework? Is it a data access layer for some of your company data? If so: JPA is a kind of a standard and might be a good fit since it is widely used. If other people should use your "framework" it is good to use something which is standard and used in many other applications and tools.
Do you really need a data access layer on the desktop? Do you have a rich client? It is no problem to just "deploy" the application to the desktop, but a data access layer must always be configured and (maybe) updated. And that's where the pain begins when you use a rich client. Users must configure a database, the database must be installed or accessible remote and the version of the client must match the version of the database. Sooner or later this will hit you.
What else have you considered already? What about a ORM? Hibernate might by a good and popular fit. Also eBeans which is used in Play! is very cool. If you make a CRUD applications, frameworks like eBeans are doing most of the work out-of-the-box for you. You create a model (just POJOs + annotations) and the frameworks provides the complete data access layer (including the database setup).
I've been doing some reading lately and one thing that I've come across was this article about the Anaemic Domain Model from Martin Fowler. I know, it's old, but somehow very actual in Java world. So I'm trying to move towards a more domain-driven design. One option would be to go with the Active Record model. However, I don't really like the current implementation it has in Scala. It completely couples the domain objects with the persistence type (not so bad in most cases but I have a project where I need to store something both in a RDB and in Mongo). Then I ran across this article about Spring, Hibernate and Scala and though here too the domain object is coupled with the JPA trait, I noticed how he uses Spring to inject a Notification Service. Can't the same mechanism be used to inject a transparent DAO interface? Have you seen this used anywhere? Any thoughts on the idea?
You should have a look at Spring-Data, this project provides some kind of abstraction over different data storages.