Repository interface method names

[Maciej Hadam]

As i see repository class has by default CRUD operations
(operation - operation in GenericJpaRepository class)
CREATE - persist
READ - load
UPDATE - save
DELETE - delete
)

I propose to use interface as below:
public interface GenericRepository<T, PK extends Serializable> {

PK create(T newInstance);

T read(PK id);

void update(T instance);

void delete(T instance);
}

Clear mapping of CRUD pattern operation names to interface method
names.

[Sławek Sobótka]

Yes, but this was meant to look/sound like mismatch.
Kind of rhetoric figure that clearly presents that Repo is not just
about CRUD. We wanted to break mental association with DAO pattern -
which is considered as a CRUD operations container.

Reasons to expose DAO difference:

LOAD vs READ:
- Repo may perform additional logic: injection, assembling based on
some rules
- Repo is not just about reading data - in general Repo may read
chunks of domain aggregate from different sources (not only DB) and
assemble them. Rare but I have seen system where Repo talks do few
DAOs
- Using Event Sourcing we are actually reading events at than loading
them to the Aggregate - so aggregate is loaded from Events.

CREATE vs PERSIST
- create is concept from "DB-oriented" system, where created means
"stored in db".
- in DDD Aggregate begins it's life in a Factory (which creates it),
and persisting is a step of the process - db is just a technical
detail

Actually it can be considered having just one method: save which
creates or updates aggregate - just like Hiberbate's saveorupdate.


So it looks like just a convention detail, but there is a bigger
meaning behind it.


Sławek Sobótka

[Maciej Hadam]

Yep, you are right. Now I see the "evolution step" from GenericDAO
(you mentioned about it in WIKI)

[Marcin Kuthan]

Do you considered spring-data as a genericrepository infrastructure? I found that spring-data is:

* not intrusive 

* easy to extend

* eliminate boilerplate code (define method in repository interface and corresponding named query)

* quite nice abstraction over JPA criteria (DDD specification)

There are also disadvantages (I don't like the following concepts):

* generate JPAQL based on method singnatures

* @Query annotation for inlined JPAQL

* Auditing stuff

Marcin

[Sławomir Sobótka]

actually not:P

because we want to stick to the "non invasive philosophy" which means:
- if someone want to extend Leaven in this way - than no problem
- if someone want to get rid of Spring and rewrite to
EJB/Seam/whatever - challenge is easier
- we want to keep learning curve as flat as possible - advanced
engineer can add Spring-data with no problem, beginner will cry if
need to learn another framework just to understand something so
relatively simple as DDD and CqRS.

[Marcin Kuthan]

Good point, I fully agree. But there is a danger that genericrepository will become spring-data like infrastructure over the time. 

"understand something so relatively simple as DDD and CqRS" - very funny ;-)

[Sławek Sobótka]

> Good point, I fully agree. But there is a danger that genericrepository will
> become spring-data like infrastructure over the time.

GenericRepo is just a impl. detail:)

> "understand something so relatively simple as DDD and CqRS" - very funny ;-)

I really mean it.
Domain modeling - thats a challenge. But implementing it is just about
rational OO and can be done using any simple "stone-age" tools. CqRS -
the same.

Deeper meaning is that: most important is to balance accidental
(technical in this case) complexity and essential (domain model).
Understanding how a bank, a hospital or big company works is enough
problem - there is no need to add more problems.

[Marcin Kuthan]

The technical (not domain) implementation of DDD is also tricky.  Eric wrote the book ~7 years ago, but there is still lack of DDD implementation principles for Java ecosystem. There must be a reasons behind that:

1. complexity ???

2. lack of good OO developers/designers in the "transactional scripts" ages

But this project is a fresh breeze :-D

[Sławomir Sobótka]

> The technical (not domain) implementation of DDD is also tricky.  Eric wrote
> the book ~7 years ago, but there is still lack of DDD implementation
> principles for Java ecosystem. There must be a reasons behind that:
> 1. complexity ???
> 2. lack of good OO developers/designers in the "transactional scripts" ages

Personally I know many very competent people who could provide DDD
sample. Much better than our Leaven.
But being too competent is associated with one disadvantage: you know
that you know nothing:)
So I guess that many people are blocked by some kind of fear... maybe?

> But this project is a fresh breeze :-D

Thanks for a good words:)