Clean Architecture - Entities - People are Confused?
8,172 views
Skip to first unread message
Dave Schinkel
Aug 30, 2015, 4:22:47 AM8/30/15
to Clean Code Discussion
I'm seeing various definitions of what "Entities" are to people who are aware of UB's Clean Architecture.
Clearly, as I recall, UB refers to Entities as Domain Entities. In other words, they are the objects that contain reusable Business Logic (Domain Logic).
But I see some people out there thinking they're DL Entities in their examples because the methods in there are persistence based methods. For example this chap, when I looked at his entities in his library folder, they're basically repository type CRUD actions https://github.com/qertoip/guru_watch. That's wrong because I believe when we talk about the term Entities in Clean Architecture.
Not sure why there is a difference in view on this when UB makes it very clear in his video. Maybe people are reading about it and really need to instead watch his Video (episode 7)!
vivek poddar
Aug 30, 2015, 2:29:03 PM8/30/15
to clean-code...@googlegroups.com
Hi Dave,
I am a newbie and I build a small project showcasing clean architecture.
https://github.com/vivekimsit/short_url/blob/master/entities/short_url.rb
Here you can see that my domain entity is just a plain data structure independent of any layer. It has some validation logic but that's completely generic.
wdyt?
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, 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.
Dave Schinkel
Aug 30, 2015, 7:53:29 PM8/30/15
to Clean Code Discussion
Yes saw that thanks.
I thought though that in the Clean Architecture Model, "Entities" ==> "Business Objects that are not data objects They're business domain objects that contain application agnostic business logic that can be used for any application and ignorant of persistence and ignorant of any application context".
So for me I think your Entities are really Data Models and should be named as such.
Let me know if anyone disagrees. Because this Entity thing is making me nervous. I feel what UB is saying Entities is not what people are doing, they're really explaining models.
And then you bring up a good question, where should the validation live.
On Sunday, August 30, 2015 at 1:29:03 PM UTC-5, vivek poddar wrote:
Hi Dave,
I am a newbie and I build a small project showcasing clean architecture.
https://github.com/vivekimsit/short_url/blob/master/entities/short_url.rb
Here you can see that my domain entity is just a plain data structure independent of any layer. It has some validation logic but that's completely generic.
wdyt?
On 30-Aug-2015 1:52 pm, "Dave Schinkel" <dsch...@gmail.com> wrote:
I'm seeing various definitions of what "Entities" are to people who are aware of UB's Clean Architecture.--Clearly, as I recall, UB refers to Entities as Domain Entities. In other words, they are the objects that contain reusable Business Logic (Domain Logic).But I see some people out there thinking they're DL Entities in their examples because the methods in there are persistence based methods. For example this chap, when I looked at his entities in his library folder, they're basically repository type CRUD actions https://github.com/qertoip/guru_watch. That's wrong because I believe when we talk about the term Entities in Clean Architecture.Not sure why there is a difference in view on this when UB makes it very clear in his video. Maybe people are reading about it and really need to instead watch his Video (episode 7)!
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.
Antônio Carvalho Jr.
Aug 30, 2015, 9:05:37 PM8/30/15
to clean-code...@googlegroups.com
I see entities as described by Eric Evans in DDD. Basically, they are objects that have identity.
They do are unaware of the persistence, but they still have state (data), thus having private fields and such.
Having state (fields) and behavior (methods) is just good OOP. Having objects that only contain methods, and no data, is what they call "Transaction Scripts", and is the key to getting yourself into anemic domain models.
Because the system will not be running 100% of the time, the entities probably have to be persisted somehow. In DDD lingo, the Repositories provide such service (persistence) to the Entities. But this data mapping, the ORM stuff, is implementation detail of the Repository, thus belonging to a layer other than (outside of) the domain.
The entities could have a simple mapping to, say, a relational table, yes, but that's not their goal at all. If anything, it should be a coincidence.
HIH,
---
acdcjunior
To unsubscribe from this group and stop receiving emails from it, 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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
Antônio Carvalho Jr.
Aug 30, 2015, 9:16:50 PM8/30/15
to clean-code...@googlegroups.com
I just noticed, in Uncle Bob's Clean Architecture diagram, the innermost circle, "Enterprise Business Rules", has the name "Entities" on it.
From his description, then, seems to me that what he means by Entities probably is a little more "broad" than what Evans described as Entities in DDD. I'd say that UB's entities == DDD's entities+value objects+factories+domain services, or something like that.
In other words (again, as I see), Entities in Clean Architecture aren't just objects with identity, they include these, but also include some other kinds of objects (without identity, with other goals), needed to implement the business rules.
---
acdcjunior
Dave Schinkel
Aug 30, 2015, 11:52:58 PM8/30/15
to Clean Code Discussion
Exactly, you hit my frustration on the head...There are some grey areas with the terms and different people use those terms to mean different things. I need to read evan's entire book because I don't know if he's refering to entities as business objects or plain data objects that are simple data structures but geared toward the business, not data structures that mimic the database structure.
The problem is people use certain words interchangeably to mean different things depending on what person, book, video you reference.
Lets break this down together and I need your help. If you are viewing these things differently, lets bring that up into the open, I think this will be a good discussion for all.
3 Types of Objects
In UB's words below, he talks about Igor Jacobson's 3 Main Types of Objects
- Entities
- Ivor Jacobson refers to "Entities" as what we like to refer as "Business Objects"
- Repositories of application independent business rules
- methods in these objects perform functions that can be valid for any applications that the entity object can be used in
- (my translation: in other words any applications which see any of these object's functions useful should be able to use them, they're application independent generic business logic)
- Interactors
- Repositories of application specific business rules that implement a use case
- hence Interactors are use-case specific
- Any Application specific business rules belong inside an interactor objects
- They call also application agnostic logic (business logic in Entities)
- Accepts input data from the user in the form of data Models (application agnostic simple data structures)
- Returns back data models
- Boundaries
- These objects isolate the use cases from the delivery mechanism and provide a communications pathway between the two
Types/Names of Layers in an Application You Hear talked about often
- Presentation Layer
- Controllers Layer
- Interactors Layer
- Business Layer
- Repository (or Gateway) Layer
- Data Layer
And then Gateway Entities Layer, and Gateway Entity Implementation Layer - this is what's grey here to me.
- Is this essentially like a repository layer? Or are these "Entities" in these gateway objects the Business Objects referred to as "Entities" in Clean Architecture based on Igor Jacobson's intent in that they contain business rules? If so, where are the Domain Models that are data structures that have no logic and are transport models from your Repository objects back up to your Domain Entities? or passed Back up to your Interactors?
Now here is a list of Terms I've heard people and also myself refer to, but sometimes Referred to mean Different things.
It's important for me to distinguish wtf people mean because when we communicate with each other, this crap can provide all sorts of confusion on the person you're talking to means, and whether you're both on the same page or not.
These terms and variances are what we need to decipher and clear up.
So let me know if I'm on the right path here with any of this or not:
Data Model
- Pure & Simple Data Structure
- Only has properties and values, no logic, no state, plain POCO object with data
- Examples: request model, response model
- Passed to Interactors and passed back from interactors back to boundary objects
Domain/Business Entity
- Hold application agnostic business rules that any application could use if it sees fit and sees them useful
Data Entity
- Don't know, do people use this phrase? I can imagine probably, and if so who knows WTF that means :).
Data Object
- My Interpretation and use:
- your typical Data Layer objects that are closest to your database, and they are simple data structure Model Objects that are modeled exactly how your Data Layer schema is
- These are passed up to the repository I think? Then your repository somehow translates them to Domain Models which are more business-like data structure models that solve the impedance mismatch issue
My Grey area right now is "Entities" and then The Repository layer would I believe return Entity Models to the Interactors (but not to the entities? Or maybe to both?)
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.
Dave Schinkel
Aug 30, 2015, 11:56:41 PM8/30/15
to Clean Code Discussion
And then I think your "Transaction Scripts" is AKA "Business Objects" or "Entities" that UB describes (Igor Jacobson) and they contain I think only application agnostic business rules (exposed by public methods).
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.
Dave Schinkel
Aug 31, 2015, 12:01:34 AM8/31/15
to Clean Code Discussion
And so what you are concluding is that the Repository does the converting of the Business Data Entities to the Database (translation impedance).
So that's what bugs me or is confusing.
I'd want to call those DDD Entities something else because what happens is people talk about "Entities". Which could mean two completely different things depending on context. "Entities" could refer to Business Objects OR "Entities" could refer to dumb data structures that hold only state via properties and hold no methods and are used to pass up from repositories to higher layers like the Interactors, etc.
Also maybe I'm on the wrong view of Business Objects. Maybe they (UB calles "Entities") should hold both state AND application agnostic business rules? And then the repositories would take in the Business Entities and extract the data (state) from them and persist that data back down to the DB (via mapping)?
On Sunday, August 30, 2015 at 8:05:37 PM UTC-5, Antônio Carvalho Jr. wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.
Dave Schinkel
Aug 31, 2015, 12:02:50 AM8/31/15
to Clean Code Discussion
In other words (again, as I see), Entities in Clean Architecture aren't just objects with identity, they include these, but also include some other kinds of objects (without identity, with other goals), needed to implement the business rules.
I think so...this is what drives me crazy.
UB!!!! ???? If you see this thread, Please comment :).
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.
Caio Fernando Bertoldi Paes de Andrade
Aug 31, 2015, 6:18:08 AM8/31/15
to clean-code...@googlegroups.com
Here's my two cents:
The definition of an Entity isn't written in stone for a good reason. The definition must be flexible enough so you can give it the shape you need to express any business rule, even the complex ones.
If you've got all your dependencies right, pointing from your concretions to your abstractions, away from frameworks and libraries, and you've got all that well tested, this entity layer is your reward. You've earned it. Enjoy it.
This is where you're free to experiment. Follow Evans's take on how to express complex rules if you like. Let your tests guide your design. Keep your mind open to identify opportunities to use design patterns inside your domain. No one knows your domain best than you and your user. It's your responsibility to understand the real domain problems and turn it into domain code that solves the problems.
So here's what I think we all should be discussing: entity design patterns. I think we should share the shapes we've given to our entities in the apps we've developed, so we can learn what's possible, what's positive and what's negative in each case. What do you think?
Caio
To unsubscribe from this group and stop receiving emails from it, 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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, 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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
Dave Schinkel
Aug 31, 2015, 9:50:36 AM8/31/15
to Clean Code Discussion, caio...@icloud.com
Ok so I'm trying to distinguish what an Entity is for. Is it a simple Data Object or Business Object? A Model would be a simple data object with no behavior. What's an Entity then? Is that passed back as a simple data object from a Repository Object? Or is it a Domain Layer Business Object?
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.
Caio Fernando Bertoldi Paes de Andrade
Aug 31, 2015, 9:51:27 AM8/31/15
to clean-code...@googlegroups.com
An Entity is a business object, not a data structure.
UB is very clear on that distinction.
Caio
To unsubscribe from this group and stop receiving emails from it, 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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, 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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, 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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
Dave Schinkel
Aug 31, 2015, 10:34:59 AM8/31/15
to Clean Code Discussion, caio...@icloud.com
totally, yes that's my beef. There are others that treat that term as meaning data structures. It just makes it confusing.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.
Caio Fernando Bertoldi Paes de Andrade
Aug 31, 2015, 10:49:28 AM8/31/15
to clean-code...@googlegroups.com
This confusion comes from the issue: should gateways return entities or data structures?
UB says that any boundary should only be crossed by data structures, so you can conclude that gateways shouldn’t return entities.
UB also showed flexibility on this specific issue, saying he doesn’t think it’s too bad for a gateway to return entities, because you can do some intersting things by following this approach (like lazy loading and other stuff). He said this is an exception to the rule, and AFAIK it’s the only exception.
I personally don’t like to return entities in my gateways. Whenever I feel the need to use lazy loading, I search for a better design to solve the persistence performance issue.
Caio
To unsubscribe from this group and stop receiving emails from it, 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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, 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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, 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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, 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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
Dave Schinkel
Aug 31, 2015, 12:57:32 PM8/31/15
to Clean Code Discussion, caio...@icloud.com
Yes that's where my confusion is, with Gateways.
Thanks great comments. Helped.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.
Shaun Whyte
Sep 1, 2015, 11:02:58 AM9/1/15
to Clean Code Discussion, caio...@icloud.com
Hi Caio, Dave
Could you point me to the video where he talks about the entities not crossing boundaries except across gateways, I think I need to re-watch that one.
I recently re-watched episode 18, which is the Component Case Study episode... if you've bought this one, you can download the extras that contain a bunch of useful diagrams he presents in this episode... it also goes in to a little more detail on the entities. One thing I've tried to adopt from this is to create "abstract entities" which the interactors use, and they pass these abstract entities across the gateway boundaries. These abstract entities contain both abstract methods to get and set data, and also concrete methods which contain the application independent business logic. Down in the bowels of the gateways on the other side of the boundary, these abstract entities are extended to become concrete entities, which are specific to the gateway implementation.
So, imagine we have a "Person" abstract entity class, this contains all of the application independent business logic exposed by its methods (e.g. isOldEnough() method in this abstract class might contain business logic to check that "getAge()" is greater than 18). But the getters/setters that set and get the data would be marked as abstract because they don't contain any properties. The properties and the implementation of the gets/sets are done in the concrete implementation classes in the same layer as the gateway implementation. This allows the specific entity implementation classes to annotate then or use any framework they like to populate the data within the object, which is exposed in some way through the business methods.
Dave - I definitely agree there are a lot of overloaded terms used, and I think you're on the right lines with your last statement on what UB calls entities - they contain both application agnostic business logic, and state. But I seem to remember UB was making a point that what is important to the application is not what it holds (it's state), but what it can do... from this I inferred that the state was simply a means to be able to provide its behaviour... or something along those lines. This is why there are no properties declared in the abstract entities, only abstract methods where it's left to the concrete implementations as to how to provide that.
Whether then we need to have the "Data objects" as Dave has described above, I'm not sure.... maybe the concrete implementations of the entities at the gateway layer is good enough to also act as the data objects.
Interested on what peoples take is on this.
Thanks,
Shaun.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.
Israel Fonseca
Sep 1, 2015, 12:15:11 PM9/1/15
to clean-code...@googlegroups.com, caio...@icloud.com
Uncle Bob showed this in one of his talks:
This clearly shows, that at least in some point of his life, his indeed thought that it could be a good idea (this is from 2011, one year before the CA blog post). In his codecasts, he does like this too.
I personally tend to like this approach because it have less code to write. I don't think that for medium-sized applications sharing the entity across gateway boundaries would be big problem.
To unsubscribe from this group and stop receiving emails from it, 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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, 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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, 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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, 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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, 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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
Caio Fernando Bertoldi Paes de Andrade
Sep 1, 2015, 12:57:09 PM9/1/15
to clean-code...@googlegroups.com
Shaun,
In the CleanArchitecture blog post (http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html), in the section What data crosses the boundaries, UB writes:
"Typically the data that crosses the boundaries is simple data structures. You can use basic structs or simple Data Transfer objects if you like. Or the data can simply be arguments in function calls. Or you can pack it into a hashmap, or construct it into an object. The important thing is that isolated, simple, data structures are passed across the boundaries. We don’t want to cheat and pass Entities or Database rows. We don’t want the data structures to have any kind of dependency that violates The Dependency Rule."
This may appear to be contradictory to what he said in episode 18. But note that he said only data access methods should be implemented in the entity gateway implementation. So, although we are passing entities around, we are making sure only the pure data used by the entity gets fiddled with in the gateway, so we don’t violate the dependency rule.
It’s almost the same thing as if the gateway built a complete data structure with all the data the entity needs, handed this struct to the interactor which would pass it to an entity constructor in order to use the entity’s business rules. The benefit of the gateway implementation approach is not having to get all data prior to their iminent need, so you can do things like lazy loading or dealing with some temporal coupling.
Caio
On Tue, Sep 1, 2015 at 1:15 PM, Israel Fonseca <israe...@gmail.com> wrote:
Uncle Bob showed this in one of his talks:
Message has been deleted
Dave Schinkel
Sep 1, 2015, 6:38:23 PM9/1/15
to Clean Code Discussion, caio...@icloud.com
All,
Check out some sketches I did today on how I plan on applying Clean Architecture for our Node.js REST API.
Any feedback welcome. I'm only going to share that for a bit, then take it down. There are 2 pdfs.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@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.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.
unclebob
Sep 3, 2015, 12:31:02 AM9/3/15
to Clean Code Discussion
My view of Entities is that they contain Application Independent Business rules. They are not simply data objects. They may hold references to data objects; but their purpose is to implement business rule methods that can be used by many different applications.
Gateways return Entities. The implementation (below the line) fetches the data from the database, and uses it to construct data structures which are then passed to the Entities. This can be done either with containment or inheritance.
For example:
public class MyEntity { private MyDataStructure data;}
Gateways return Entities. The implementation (below the line) fetches the data from the database, and uses it to construct data structures which are then passed to the Entities. This can be done either with containment or inheritance.
For example:
public class MyEntity { private MyDataStructure data;}
or
public class MyEntity extends MyDataStructure {...}
And remember, we are all pirates by nature; and the rules I'm talking about here are really more like guidelines...
And remember, we are all pirates by nature; and the rules I'm talking about here are really more like guidelines...
Breno Sarkis
Sep 3, 2015, 6:39:00 AM9/3/15
to clean-code...@googlegroups.com
I'm using a different approach when it comes to Entity design, I wonder if we're achieving the same result at the end of the day.
I'll allow my Entities to have getters and setters, but I make them abstract. Instead of doing MyEntity extends MyDataStructure {...}, I have a DataStructure at the Gateway level that inherits from MyEntity and define how to fulfill the getters and setters, 100% of the time so far, this is done by hitting the DataBase.
One thing I dislike about how I'm doing things is that, when you don't have a company, thus no ("Application Independent Business rules") you end up with Entities that are more about the Data. Even though it's still all abstract.
--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages