[Bug]: Breaking SOLID principles and Clean Architecture.

[Yazon2006]

Is there an existing issue for this?

• I have searched the existing issues

Is there a StackOverflow question about this issue?

• I have searched StackOverflow

What happened?

Somebody sent me your project as a best example of Clean Architecture and the only one right reference from Google for those who study programming (meaning that this is the only one unbreakable existing source of truth of architecture).
I open the dependencies and see that domain layer depends on data. Which has no sense if your definition of the domain is the same as canonical definition of pure business logic layer.

It would be nice to add a disclaimer that the domain layer from this project has nothing in common with Clean Architecture's domain except the title. Or you may use other title for your layer because the domain logic can not depends on the data source implementation. E.g. "logic" layer, but not domain. It's very confusing because you substitute widely known definition of the domain layer with your own one and it gives wrong direction for those who can't argue against the huge Google authority.

On other hand you may slightly refactor the project by changing the way of dependencies so the data layer will depends on domain layer. In this case you'd need to define repository interfaces inside of the domain module and create their implementation inside of the data layer. It will cost almost nothing in terms of implementation efforts but will bring much more clarity for those who try to google question like "data layer depends on domain".

People already started asking questions.

In my opinion it's a major architectural issue because the data layer implementation should depends on abstract domain logic (including abstract repository interface) but not vice versa. Without doubts it's up to you keep everything as is but in this case I'd kindly ask you to add disclaimer directly to this project readme file with some clarifications and explanations.

Looking forward for your thoughts. Thanks in advance.

Relevant logcat output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[SimonMarquis]

Disclaimer: I'm not affiliated with Google in any way.

Thanks for raising your concerns (that I personally share as well), but I don't think Google ever said they were following "the clean architecture". Not on their official documentation, not on this project either.
I understand that re-using the same terms can be confusing, but there are not a lot of choice, and naming things is hard. It's like saying MVVM can't use the terms "View" or "Models" because MVP already used them before. 😛
They could probably add a disclaimer somewhere in here though.
But keep in mind that this is just one way of doing architecture, and Google does not force anyone to use it as-is.
That being said, this project is probably not the best place to make your voice heard, as this repository is only reflecting what the official Google recommendations are at this time. Providing feedback or participating in official Q&A might be more effective.
If the maintainers of this project could clarify the situation, it would be great.

[dturner]

Thanks for raising this. Let me try to provide some clarity. I'm an engineer on the Android DevRel team at Google and I'm the Tech Lead on this project.

Why doesn't Now in Android use "Clean Architecture?"

As @SimonMarquis said, Now in Android is intended to be a real-world implementation of the official Architecture guidance (as well as many other best practices for testing, UI design etc). As you have pointed out, the official guidance is different from "Clean Architecture" in two fundamental ways. In the official guidance:

• the domain layer is optional
• the domain layer depends on the data layer, not the other way round

Why doesn't Google just recommend "Clean Architecture"?

Many apps aren't complex enough to justify having a domain layer. This is why in the official guidance the domain layer is optional. You can build your app with the UI layer dependent on the data layer, then introduce the domain layer later if the need arises. Ultimately we feel that the official guidance offers the best approach for most Android apps.

It's worth saying that the official guidance is just that: guidance. It's not intended to be a one-size fits all. Developers should question whether the ui->(optional domain)->data approach is right for their app's requirements.

What are the benefits of the official Android guidance over Clean Architecture?

• Less rigid. You can start off with just UI and data layers, introducing the domain layer only when it's required for your app to scale.
• Easier to change where data is stored (e.g. by moving from preferences to a Room database or local to cloud) since the data layer isn't dependent on any other layers.

What are the benefits of Clean Architecture over the official Android guidance?

• Easier to change business logic. Clear encapsulation of this logic from the outset. No business logic in UI or data layers.
• In Android apps strictly following Clean Architecture, the business logic is usually contained in plain JVM library modules (which have no Android dependency). This can be useful in cross-platform apps.

Hopefully that answers some of your questions.

One question in return (to @Yazon2006): you mentioned that Now in Android is breaking SOLID principles - where? I'm not saying it's perfect but I don't see any glaring violations of SOLID.

Happy to discuss further.

[Jaehwa-Noh]

Oh, It seemed to matter of definition of module.

[Yazon2006]

"module" doesn't imply "Gradle module"

As well as term "import" doesn't imply "java class import. Think of it in other way. Domain layer transitively add dependency on data module which contains database, datastore, network. It doesn't makes sense because the logic in usecase do not depends on use we ktor or retrofit.

But this doesn't change anything much.

This is dramatically changes everything. In case if we split data into data-api and data-impl so that the

• data-api will contain only interfaces and depends on core.model
• core.domain will depends on data-api and core.model

then the core.model + core.domain + data-api will effectively form the domain layer in it's classic definition and the data-impl will depends on part of it. That's the same as "make data depends on domain" but even more precise in terms of separation of concerns.

The simplest example of domain layer is when we have models + interfaces + usaceses in one module. But it's dangerous because in growing project the complexity of this module will lineary grow and become most complex non scalable part. With -api/-impl/etc modules concept we always can extract piece of domain knowledge into separate -api feature module, reuse it in other feature without exact implementation. We can go even further and extract -model into separate module. But there should be always the same rule: impl will depends on api, not wice versa.

As long as entities from the domain module do not import implementation details from the data module

How many trainee/junior and even middle devs can break this rule using current dependency direction setup? I remind you that this is an example from Google. It's a Holy Scripts of android development community. Can they resist temptation to import retrofit dto model into usecase to avoid creating dto->domain mapper? It's absolutely easy in this project. We can even avoid creating model in core.model and use only publicly available dto model in all data-domain-presentation layers.

[briandr97]

What are the benefits of the official Android guidance over Clean Architecture?
Easier to change where data is stored (e.g. by moving from preferences to a Room database or local to cloud) since the data layer isn't dependent on any other layers.

@dturner I disagree with this: why do you think it's harder to change where data is stored in a Clean Architecture? I think it's still easy to change data source(where data is stored) in the data layer when we use Clean Architecture
Whatever changes happen in the data layer, the data layer only needs to implement the interfaces of the domain layer. Therefore, changes in the data layer don't propagate to other layers.

However In Android guidance, data layer is purely independent and other layers such as domain, ui should depend on data layer. So data layer should be stable. It is difficult to change a software component that many other components depend on it.

You might say that since an interface exists between the data layer and the other layers, you can change data source without changing the interface.
Even taking that into account, it cannot be said that CA is more harder to change where data is stored than Android guidance.

[dturner]

Yes, you're right to challenge that point. If you follow good design practices it shouldn't be any easier to change the data layer in the official guidance vs Clean Architecture. The difference occurs if you have a naively designed data layer which does not use interfaces and instead relies on concrete implementations. In this scenario it would be easier to change the data layer because your implementations are not dependent on the domain layer.

[briandr97]

Thanks for your response.
I agree that if an interface exists between layers, there is not much difference between the two architectures in terms of changing where data is stored.
However, your assumption of no interfaces is difficult to understand. Because in CA, dependency inversion through interfaces is essential.
I think I would agree if you are saying that CA has a higher barrier to entry than Google guidance because it requires an understanding of inter-layer dependency inversion.

[Jaehwa-Noh]

Wait... Are they clean architecture and Google's architecture guideline different?
I have another question.

I saw this two images.

[figure 1. Clean architecture]

[figure 2. Google's architecture guideline]

Both look similarly same to me.
Let's rotate figure 2.

[figure 3. Google's architecture guideline(Sorry for rotating)]

figure 3 looks like figure 1.

I thought I can connect each others architecture's.
Clean architecture -> Google's architecture guideline
• UI, Presenters -> UI Layer
• Use Cases -> Domain Layer
• Entities -> Data Layer

What do you think about my idea?
If both are different, what did I miss the point of view?

Thank you.

[dturner]

Sorry, I accidentally started a new thread below instead of replying directly.

[Jaehwa-Noh]

It's ok. I can feel that reply was for me.

[dturner]

You're right, they are similar, but not identical. The differences are highlighted in red below:

As an exercise, it could be interesting to migrate the existing architecture to clean architecture. It should be a relatively simple refactor to move the :core:data repository interfaces into the :core:domain module, reversing the dependency.

For strict adherence to clean architecture, you'd also need to write wrapper functions in the domain layer to remove the ui->data layer dependency

[dturner]

Yeah, my point was that if you are adopting Clean Architecture where it is mandated that the repository interfaces reside in the domain layer you don't need to provide UseCases for all repository methods.

I agree that having data repository interfaces in the domain layer feels kind of strange, however, I guess the point is that in Clean Arch you are prioritising business logic over everything else. The repository interfaces represent the contract which all data providers must conform to, and therefore should reside in the domain layer.

To me, this is splitting hairs though, as long as you are actually splitting interfaces and implementations, whether that's:

• within the same module (which is what we do in NiA e.g. :core:data)
• separate api and impl modules (good suggestion)
• or in a domain module (Clean arch).

it's actually not that important. What is important is that people understand the project architecture and use it correctly.

I will say that in my (extremely biased) opinion (and this is backed up by your comment @arkivanov) the official architecture is easier to grasp from a conceptual level, simply because the dependency arrows all go the same way.

[Yazon2006]

From my point of view having repository interfaces in the domain layer is not good.

So then lets follow Separation Of Concerns principle as stated in docs

Define domain with definitions and relations:

Models aka simple pojo classes for domain entities. E.g. Car, Human, etc. Then relations. Human that drive the car is Driver. Than you define the abstractions for data sources for Cars, Humans. E.g. buyCar(money: Money): Car; hireDriver(money: Money). Then some logic getCars+getHumans=makeTheRace. That's all about the domain. If you wan't you may split it in as many sublayers as you want. E.g. in this repo core.model could be the bottom part, data-api somewhere between core.model and business-logic. And the business-logic will include two previous.

Now we can proceed with implementation:

We depends on everything that I described above. We may have different features that use any described particle model/data-api/domain-logic. And indeed everything above the model level is optional in terms of some particular feature needs. Let's say I develop advertisement feature. I don't care about data sources or logic, I only need models. My feature will use models to create slogan: "Best Cars for Humans". That's it. No necessity to depends on data-api/business-logic. Or I may wan't to create some specific feature with some specific logic that depends only on data source, e.g. getHumans+getCars=makeTheExhibition. Then it obviously will depends on model/data-api without business-logic. Or just some simple UI mostly module that will consume the business-logic including model/data-api.

Then it will increase the complexity of the project sctructure but bring more separation of concerns.
In case if we want to go back to simplify the project we may combine model+data-api+business-logic into one big domain layer and everything would be fine except the scalability problem. That's always a trade off.

And all of that starting from basic models and up to the place where we start talking about UI that's the domain. The domain definition is not limited only to UseCases. That is what I'm trying to explain from the very beginning. The definition of the domain in documentation is wrong. The domain can't be optional while usecase can be.

Rename the "domain" layer in docs to "business-logic" and you'll get traditional layered architecture:

(Hello 2000)
Where the business logic depends on the exact data source. It's when you need to rewrite UseCase as soon as you would need to migrate your app from home ftp server to Amazon AWS. It's when migration from Retrofit to Ktor require domain layer changes. It's when the definition of Car depends on exact shop you buy it from.

the official architecture is easier to grasp from a conceptual level, simply because the dependency arrows all go the same way

I have nothing against this approach. It still widely used. But if google recommend something then it would be really kind from their side to let users know about disadvantages of such approach at least.

We obviously see that we may change the direction of the injection and get independent "domain" layer. Where the situation when the logic depends on exact implementation would be not possible.

For experienced developer this repository is just another example of architecture. We may take what we wan't from here and forget about the rest.

But for those who study, for those who has no strong opinion this repo is the single source of truth. They'll take this project as a barebone for their pet projects. And will build interfaces and logic depends on the exact data sources. And then they will came to all of us on the interview with examples of how they thought Clean Architecture just because it has domain layer =). It's not CA example and will not be after proposed changes. Moreover as I said I don't like CA because it's complicated. But this project is not much easier than CA for understanding. So we will not takle all the problems at once. But the dependency direction rule change is a low hanging fruit that without doubts worth to pick up.

[dturner]

The definition of the domain in documentation is wrong.

It's only wrong if you take it out of context and assume that it applies to Clean Architecture. It isn't wrong in the context of the official Android architecture guidance.

Where the business logic depends on the exact data source. It's when you need to rewrite UseCase as soon as you would need to migrate your app from home ftp server to Amazon AWS. It's when migration from Retrofit to Ktor require domain layer changes. It's when the definition of Car depends on exact shop you buy it from.

No-one is suggesting this and this is not how Now in Android is implemented.

The data layer interfaces represent the public contract with the domain layer, not the underlying implementations. For example, in Now in Android you could change from Retrofit to Ktor simply by adding a KtorDataSource which implements NiaNetworkDataSource. No UseCases or repository implementations would change.

To be clear, we are still using (and recommending) dependency inversion (as explained in the modularization section of the official architecture guidance). It's just applied at a module/object level, rather than at an architectural layer level.

[Yazon2006]

@dturner Ok, I got your point. I already said everything I had. If you insist that the definition of domain in your docs is ok then so be it. If you think that domain dependency on data is ok I'm fine with it. Just please, add some disclaimer in docs and into repo readme. Something like: "Our definition of "domain" is different from the definition of "domain" that is used in Clean Architecture by Robert C. Martin or/and Onion Architecture by Jeffrey Palermo". That's all what I ask. Hope it makes sense.
P.S. Such disclaimer can explain most of architectural peculiarities.

[dturner]

Added a note to the architecture docs for the project (will merge once approved) #1304

[dturner]

I decided to see how easy it is in reality to refactor to clean architecture. Summary: around 1 hour's work. #1277

[Yazon2006]

I precisely reviewed your PR. Looks as good as simple. That's the main step from the traditional to the onion architecture which is good described in the article The Onion Architecture from Jeffrey Palermo (year 2008, what a lovely year). So now we are more close to the classic definition of the domain layer that was described in the the Onion Architecture (the father of CA).

A small step for official Architecture guidance a giant leap for developers community.

I'd like also to mention that the domain layer can't be optional because first of all it is represented by core.model module that contains pure domain models (once again I don't see core layer in official architecture). This is actually the very bottom of the layered onion architecture. This is the true domain. The area of project wide (not only android but backend+other platforms) definitons. The Topic entity description would remain the same regardless what database we use on what platfrom etc. FollowableTopic is an entity that describes some busines logic. It show the relation between the topic and some boolean state that represents if this topic is followed or not. GetSearchContentsUseCase goes further and establish a bunch of relations between FollowableTopic, UserData, UserNewsResource inside of UserSearchResult. At this point we have such a lot of beautiful abstract sets of definitions, relations and rules. And there are no any word about exact database or some particular remote service. Android+backend+ios+anyOther would speak with each other using the same language (same definitions) described in our domain layer without knowing low level details. Isn't it a much better aproach?
This is exactly what fifth SOLID principle tells us. High-level modules (domain) should not import anything from low-level modules (module with retrofit or sqlite). Both should depend on abstractions (e.g., interfaces). Abstractions should not depend on details.

UseCases still can be optional because not all of them equaly useful. Especially talking into account examples like GetSearchContentsCountUseCase which is useless proxy class. Besides that UseCases could provide their functionality throught the interfaces to follow solid to the end. But for the sake of simplicity I suggest to do it only in case if they are used somewhere in other interface.

In case if in viewModel we'll use repository interface directly without usecase to access the data we still use domain dependency because the repository interface now in the domain layer. That mean we even have some sort of UI separation from data. Which is not required for pure android projects but why not.
I found proposed PR very positive in terms of common understading of good architecture and simple enough to be adopted.
On other hand do you have any reason not to merge it except the necessity to rewrite the official Architecture guidance?

[dturner]

Thanks for the review, and the feedback. I understand the strong feelings around this topic and will ensure that these points are raised with the team with a view to updating the guidance in future (and subsequently our samples).

GetSearchContentsCountUseCase which is useless proxy class

Agreed. This should be refactored to call the repository interface directly. Issue filed #1283

On other hand do you have any reason not to merge it except the necessity to rewrite the official Architecture guidance?

We cannot diverge from the official guidance I'm afraid, that's one of the fundamental principles of this project.

[Yazon2006]

one of the fundamental principles

But it's always good to think about revisiting principles =) We are here to change the world to better