Architecture: Entities - MAD Skills

[@kshitijpatil2019]

Following some naming conventions for these value objects helps as well. For instance, suffix remote or other DataSource models with `Dto`, suffix database models with `Entity`, consider using actual names at domain layer (no suffix) and optionally suffix with `State` at UI layer. Hence, a User model might be named as `UserDto`, `UserEntity`, `User`, `UserState` depending on the layer it belongs to.

[@AndroidDevelopers]

Thanks for the great advice, Kshitij! 😎

[@YuriyTimOk]

All right, thanks. I would add an example of a mapper. there are several implementations of the mapper: as a separate object; as a companion object inside an Entity; as a function inside an Entity; as an extension.

[@kolenyov]

I don't like they use Entities as a name for regular data objects. Everyone who has read Clean Code knows that Entities are parts of enterprise/business logic but not just a pure data structures.

[@changyichen4746]

same

[@4face91]

Ye, I don't know who started to call data structures as Entity, that confused me a lot, while studying Clean Architecture...

[@jackli1924]

Almost, but for a senario when using room databases. Use "Entity" maybe is a good one.

[@Renaro]

Very nice to see Google pushing Clean Architecture concepts!

[@jonneymendoza]

About time really. I been using clean architecture for well over 5 years in android

[@kt_radhakishan]

Very nice mam , I am from India and proud of u

[@ravipoon09]

Good to finally get some validation on this approach. 💯

[@str2254]

Ikr, it took me a while to figure this on my own trough various medium articles. Although this is knowledge about software architecture in general, not just android.

[@StraplessReligion]

Mappers are essential, if've seen too much project using entities in UI layer which end with properties needed only on certain layers

[@shehramjamil966]

mappers should not be optional. You cannot just expose network layer entity to UI. Mappers should be must

[@herbertmilhomme]

Mappers are optional because they only exist to pharse data between different [entity] formats. If the format is exactly the same, it's not inherently exposing sensitive resources, it's just leg work to go from one layer to the next.

[@technicholy1299]

It's trivial to add a toDomainObject() function to the data class and do the mapping there. That's how I go from data to domain to UI, each data class has the mapping method to the next layer in its body. When I access the object, I can just call .map{} and convert it to the other object if a list, or just call the method directly on a single object.

[@shehramjamil966]

@@herbertmilhomme Most of the times, we do not need to expose all api stuff to UI layer. Also, some fields are null able in serialized objects and we do not need them on UI layer. So instead of spreading the null able handling logic and avoiding extra unnecessary field from API on UI layer, we do mapping. UI layer does not need to handle all these things by itself. UI layer should be simple.

[@shehramjamil966]

@@technicholy1299 perfect

[@shehramjamil966]

A fun fact, mappers, DI, fragments can be avoided if you are doing a school project :p

[@AsifKhan-qb4eq]

Short and Concise.

[@sonalipawar3980]

It was nice and elaborative info about different entities at different layers

[@lifein0178]

Hi, If we create different model object in every layer, whenever a new field need to be add for any business requirement, we need to add the field in all layer's model classes isn't going to create lot of changes...?

[@dxnbrawn]

How you guys map from UI objects to domain objects and to data objects? I mean it looks simple to have .toDomainProduct() and .toUiProduct() when you map from ProductDto to domain's Product or to UI's Product, but let's say we have to show a list of Products, and each have an ID (used to fetch product details on click, for example) and we do not want to show ID on UI (or any other fields as well). So, we should omit an ID when doing .toDomainProduct() and .toUiProduct() or keep it instead, to allow pass across all layers models and mappers? Thanks!

[@smreha]

One very important point missed in my opinion. How to one type of entity to another layer entity?

[@ahmedtawfiq4723]

Excellent

[@sulzleserranochannel2447]

nice concept!🤩🤩🤩

[@sanjaydutt5679]

Fantastic

[@pms_code]

Explain with examples, that will be good

[@Renaro]

kzbin.info/www/bejne/oGO3n4SnqbOla7c

[@dr.strangelav4579]

Subtitles would have been nice.

[@aikin89]

You can open subtitles

[@viniciuscoscia]

@@aikin89 Sometimes, the auto-generated subtitles write some weird stuff. I, as a non-native English speaker, always miss built-in subtitles. Even more, when I face Indian accent, it is tough for me to understand some parts.

[@shadowxp69]

Nice

[@Mr47even]

Domain layer does not belong to ui layer ... In my point of view, if we are speaking from domain, the Domain Driven Design comes to play and should be mentioned in the video for those friends that dont know about ddd.

[@robsonsilv4.]

But this is not DDD or Clean Architecture. It's an architecture recommended by Android team (with inspirations, of course).

[@Mr47even]

@@robsonsilv4. Yes, that's right, but every architecture has a name. In this movie, they said that it should be pure kotlin, but the ui is not pure kotlin. In any case, I was not convinced.

[@GuardianMatrix2005]

@@Mr47even Jetpack Compose.

[@lokiksoni3519]

Good to see an Indian at Google

[@RogZoneOfficial]

Excellent. But, My problem is - I changed the developer name then terminated my account on 26.04.2022 Issue detailsWe found an issue in the following area(s): Developer name: “Apnasoft” You can do anything.

[@ranjiealag4578]

Hi