Skip to first unread message
Gabriele Tondi
Nov 30, 2014, 11:45:00 AM11/30/14
to clean-code...@googlegroups.com
Hi!
Today I've written this blog post with my 2cent about a particular design I've seen recently: http://gabrieletondi.github.io/2014/11/30/to-decouple-or-not-to-decouple/
The issue is this: is using observers for persistence a good practice? (when persistence is a first-class feature)
In my opinion I would prefer to call explicitly a "store" method on a gateway (using an interface).
What about you? Do you agree with that or not?
Do you feel comfortable with this type of indirection?
Thank you!
Gabriele
Frederik Krautwald
Dec 1, 2014, 11:54:09 AM12/1/14
to clean-code...@googlegroups.com
It is perfectly fine to use observers for persisting state changes. In fact, it is how CQRS+ES works; two architectures very compatible with the Ports and Adapters pattern.
One thing I noticed, however, is that you let Entities leak out of the domain when you pass your Entry to the Presenter. This is not adhering to the Ports and Adapter pattern which says that domain logic shouldn’t to leak to the outside world.
Sebastian Gozin
Dec 2, 2014, 4:33:57 AM12/2/14
to clean-code...@googlegroups.com
I've tried that approach as well though I found myself not using it for the most part afterwards.
In general I find persistence gateways don't have enough exceptional pathways to justify the approach.
Otherwise the structure does not bother me.
In general I find persistence gateways don't have enough exceptional pathways to justify the approach.
Otherwise the structure does not bother me.
Gabriele Tondi
Dec 6, 2014, 3:50:12 AM12/6/14
to clean-code...@googlegroups.com
Hi!
Thank you for you reply!
I will check and study CQRS+ES!
About the port and adapter architecture and the presenter: in my opinion the Presenter is a sort of Port, and SummaryEntryPresenter is an adapter for that port.
It will receive the entity and return a PresentableEntry value object.
The controller can finally send the PresentableEntry to the view in order to be presented to the user.
Isn't that good?
Frederik Krautwald
Dec 6, 2014, 4:37:48 AM12/6/14
to clean-code...@googlegroups.com
It
depends. If you are solely in charge of your delivery mechanism,
then it could be acceptable to pass on your Entities. However,
Entities are part of the Domain that you are modelling, and as
such nothing should leak outside. Instead, I would suggest that
your Application Service (Interactor / Use Case) translates the
Entity into an edible DTO of some sort and passes that on to
whoever is requesting the Service, in your case a Controller
from your Presentation Layer. The Presentation Layer should have
no knowledge of the inner workings of the Application and its
Domain. If you choose to pass an Entity to the Presentation
Layer, it gets direct knowledge of the Domain. Entities reflect
the business. If a change in business requires a change in the
Domain you are modelling, which affects the Entities, then such
a change will ripple through all "layers", or everyone consuming
said Entities. Obviously, that is not good.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to a topic in the Google Groups "Clean Code Discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clean-code-discussion/iNGOmSNtVh4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clean-code-discu...@googlegroups.com.
To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at http://groups.google.com/group/clean-code-discussion.
Sebastian Gozin
Dec 8, 2014, 5:26:48 AM12/8/14
to clean-code...@googlegroups.com
While I agree with the theory I do have this gnawing impression that what we're doing here is slightly stupid.
Basically am I wrong to think that the responsibility of a controller is to trigger usecases and pass responses to presenters?
Those presenters deal with transforming the response into a format useful for transport.
So, why do we need to transform the lower level data structures into a format useful for transport to controllers?
How do we implement this? With a presenter embedded in the usecase?
Does that make the usecase a mini controller for controllers?
Anyway, I'm not sure my explanation was coherent or clear but... yeah.
Perhaps part of what I'm seeing/feeling is that when we talk about controllers we talk about components hijacked by frameworks we want to use but not depend on.
Basically am I wrong to think that the responsibility of a controller is to trigger usecases and pass responses to presenters?
Those presenters deal with transforming the response into a format useful for transport.
So, why do we need to transform the lower level data structures into a format useful for transport to controllers?
How do we implement this? With a presenter embedded in the usecase?
Does that make the usecase a mini controller for controllers?
Anyway, I'm not sure my explanation was coherent or clear but... yeah.
Perhaps part of what I'm seeing/feeling is that when we talk about controllers we talk about components hijacked by frameworks we want to use but not depend on.
To unsubscribe from this group and all its topics, send an email to clean-code-discussion+unsub...@googlegroups.com.
Frederik Krautwald
Dec 8, 2014, 3:42:32 PM12/8/14
to clean-code...@googlegroups.com
Because
when business requirements change, and they always do, we need
to re-model the domain, which most of the time encompasses
changing entities. When your UI is coupled to the domain by the
passing of entities, it, too, needs to be compiled after a
change in the domain. I am quite sure UncleBob have a video
exactly addressing this issue.
To unsubscribe from this group and all its topics, send an email to clean-code-discu...@googlegroups.com.
Sebastian Gozin
Dec 9, 2014, 4:41:03 AM12/9/14
to clean-code...@googlegroups.com
Yes, I agree that the model changes which suggests changing the transport mappers. But I don't really see the difference between changing the same number of presenters or the same number of pre-presenters.
Perhaps it's more obvious for the both of us if we try and come up with some example.
Say I have a usecase that returns a list of books for sale. This means we do not need all books as they are not all for sale.
Now in this specific UI control we don't need all details of the book. Just the title, price, description and a reference id are enough.
If this was a standalone app with a Swing GUI I could pass the list of book entities to a component implementing a special Swing interface (e.g: ListCellRenderer) for the express purpose of rendering a book for a specific Swing UI component.
As you said.
I do not want to load up the Swing project to update all those renderer classes.
I also don't want just a Swing GUI I want a CLI and REST API as well.
So at the very least we want some kind of construct in between the usecase and whatever UI we want to put on top of it.
Something which transforms the book entity into something that can easily be passed along. I think this is the transport level data structure.
In this case something which consist of only the title, price, description and reference id of the book.
At this point I've basically done what you explained right?
Now what confused me I think.
Is that you can essentially connect the Swing- and CLI UI's from my examples earlier to the REST API and I'd only have to maintain the technology specific mappers for let's say Jackson.
Of course if I wanted to switch to GSON I might run into trouble. But at the same time I'm unlikely to offer both a Jackson and a GSON based REST API at the same time no?
Can I come up with a better reason?
Perhaps I don't want to send JSON over the wire.
Yes, that could reintroduce the problem.
Ok, did I miss something or did I drop down all the way to the usecase now?
Sorry for my rambling,
Sebastian
Perhaps it's more obvious for the both of us if we try and come up with some example.
Say I have a usecase that returns a list of books for sale. This means we do not need all books as they are not all for sale.
Now in this specific UI control we don't need all details of the book. Just the title, price, description and a reference id are enough.
If this was a standalone app with a Swing GUI I could pass the list of book entities to a component implementing a special Swing interface (e.g: ListCellRenderer) for the express purpose of rendering a book for a specific Swing UI component.
As you said.
I do not want to load up the Swing project to update all those renderer classes.
I also don't want just a Swing GUI I want a CLI and REST API as well.
So at the very least we want some kind of construct in between the usecase and whatever UI we want to put on top of it.
Something which transforms the book entity into something that can easily be passed along. I think this is the transport level data structure.
In this case something which consist of only the title, price, description and reference id of the book.
At this point I've basically done what you explained right?
Now what confused me I think.
Is that you can essentially connect the Swing- and CLI UI's from my examples earlier to the REST API and I'd only have to maintain the technology specific mappers for let's say Jackson.
Of course if I wanted to switch to GSON I might run into trouble. But at the same time I'm unlikely to offer both a Jackson and a GSON based REST API at the same time no?
Can I come up with a better reason?
Perhaps I don't want to send JSON over the wire.
Yes, that could reintroduce the problem.
Ok, did I miss something or did I drop down all the way to the usecase now?
Sorry for my rambling,
Sebastian
Reply all
Reply to author
Forward
0 new messages