DDD - Domain Driven Design...who's using it? What do you think?

[Jeremy Ary]

I do see some benefit in ubiquitous language and bounded contexts and I also feel DDD goes hand-in-hand with event-driven architecture, but I'm just not a fan of the methodology altogether. The concepts of throwing out getters and setters and sticking to behavioral methods on the domain object seem to cause me more trouble than I want. For instance, JSON serialization tooling that has an expectation of getter/setter access requires me to code hacks to make the new format of models play nicely or litter annotations throughout my classes. Finalized properties on ViewModels, which are read-only by nature, are another problem in the same realm. 

Other thoughts/experiences?

[David Escandell]

hehehe " litter annotations"

I agree that while the concept of DDD is nice, it doesnt work in practice - at least not in the way we have implemented it.  To have a single implementation of an Employee, for instance, implies that it will be used in the same way every time.  If I am only using 10% of the Employee object as it has been defined by the domain, I still have to load the other 90%.  this can result in a huge waste in processing.

On Wed, Sep 24, 2014 at 7:31 AM, Jeremy Ary <jerem...@gmail.com> wrote:

I do see some benefit in ubiquitous language and bounded contexts and I also feel DDD goes hand-in-hand with event-driven architecture, but I'm just not a fan of the methodology altogether. The concepts of throwing out getters and setters and sticking to behavioral methods on the domain object seem to cause me more trouble than I want. For instance, JSON serialization tooling that has an expectation of getter/setter access requires me to code hacks to make the new format of models play nicely or litter annotations throughout my classes. Finalized properties on ViewModels, which are read-only by nature, are another problem in the same realm. 

Other thoughts/experiences?

--
You received this message because you are subscribed to the Google Groups "Nashville Java User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nashville-ju...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Greg Turnquist]

Well, careful there. You could be describing some premature optimization when you talk about fetching subsets of a single row. Kind of depends on if you are talking about a domain object contained in one table vs a record that requires joining ten tables.

At my previous job, part of our team included a prior Oracle field consultant. He educated me that when you fetch a row of data, Oracle will actually fetch the entire block all at once. Simply put, almost all the time, when someone wants one EMPLOYEE row, they will be wanting the next row pretty soon after that. It's more efficient to grab a whole bunch.

So before you tweak your code based on what you THINK is happening, do some real profiling and find out what really IS happening both in your code and the database. Run your queries through "EXPLAIN PLAIN" to see if the query is right or not and if there are ways to filter it down.

Cheers!

--
Greg Turnquist (Greg.L.T...@gmail.com)

[Timothy Pote]

A year ago, I would have disagreed with you. And my argument would have come down to "because Martin Fowler says so."

After using clojure for a year, it's impossible for me to advocate mixing data with behavior. However, in practice, it's much easier to separate the two when you have a language that's good at manipulating data. And, let's face it, Java doesn't make manipulating data easy.

So, in an imperative, OO world, my opinion is that it comes down to the codebase and the team. Do whatever is most likely to match coder expectations in this codebase, on this team.

On Wed, Sep 24, 2014 at 7:31 AM, Jeremy Ary <jerem...@gmail.com> wrote:

I do see some benefit in ubiquitous language and bounded contexts and I also feel DDD goes hand-in-hand with event-driven architecture, but I'm just not a fan of the methodology altogether. The concepts of throwing out getters and setters and sticking to behavioral methods on the domain object seem to cause me more trouble than I want. For instance, JSON serialization tooling that has an expectation of getter/setter access requires me to code hacks to make the new format of models play nicely or litter annotations throughout my classes. Finalized properties on ViewModels, which are read-only by nature, are another problem in the same realm. 

Other thoughts/experiences?

--

[Kerry Wilson]

It is true that some languages and tools lend themselves better to DDD than others, and 'true' DDD is very difficult to achieve. I have heard people finding it much easier with event-driven frameworks. Specifically, with Akka and Scala. Pragmatically, I have just held it in my mind that the domain is the best place for methods and pushed them there if at all possible and decompose them whenever possible. I am confident that if you take this approach, you will find that it saves you time down the road. As for the JSON serialization issues, that is a problem that is independent of DDD. In my experience, if you are using JPA/Hibernate, you have to have some sort of JSON serialization definition. Even if you aren't, you don't want to serialize a complete object graph (at least, not on every endpoint). FWIW, I have created a reflection-based, max depth type serializer before and it was just a bad idea.

kw

--

http://www.allthingswilson.com