Clean Architecture Core and Library Dependencies

[Christian B]

Hey guys,

When Uncle Bob talks about "your business rules should not depend open vendor libraries", i can not agree completely and here is why:

1. Do you always want to reinvent the wheel? If you want your JSON String mapped into an object, i use GSON. Do i really have to reinvent? Whats the point?

2. For data validation (StringLength, Regex etc) i want to use some validation framework (don't know yet which one) do i really have to reinvent that?

There are good libraries out there, that help me doing my job faster. They are good tested, have a great community.

It feels like, when listening to uncle bob, and i choose any framework, i get a really bad stomach because i think im not doing clean architecture.

Lately uncle bob even wrote an own webserver, i mean when is the uncle bob OS coming out?

I understand that, i would not use a web framework like spring, or a database framework like hibernate in my core, but i mean what if its real basic stuff?

[Imre Kószó]

IMO you have to make a distinction between frameworks and libraries here. You call libraries but framework calls you, I think that's very important.

If there's a library out there that is good and stable enough for your needs I don't think you should rewrite it just for the sake of purity. You will still want to have tests where the code the library provides is exercised indirectly to make sure it's doing what you expect it to do. Also, you should create your own abstractions around it so if you want to switch to another library you can do so easily. This abstraction should be simple to create.

Frameworks is another topic - because frameworks call your code it takes more careful planning not to be dependent on them. The clean architecture provides a way to achieve this.

[Christian B]

Yes, this was the exact answer i needed thank you.

[Michel Henrich]

The point of Clean Architecture is to not depend on a SPECIFIC library. Sure you can depend on a library for JSON mapping, given that this dependency is abstracted away from your application "core", so that it is easily switchable to any other library in the future, in case the current one fails you in any way. (Although I believe things like "mapping to/from JSON" are not part of the application "core", rather, they should live in the "presentation mechanism", but this is just for the sake of the example.)

Think of how the concept of Gateway serves you: It provides an abstraction from which any persistence mechanism can be implemented without causing changes in your application.

The example of Gateway is the most commonly used because the majority of apps would require some sort of persistence mechanism, but the same concept can be applied with any part you'd want to abstract away from your application.

In an application I built, I had a requirement to calculate the distance between some entities. I found out about a nice library called Geodesy that did exactly what I needed, but instead of using it right away, I first created a small interface "DistanceCalculator", that would return me a double for the distance between two points. Behind that interface, I implemented a simple adapter that delegated the calculation down to the Geodesy library, and it was done. In case I need to change the calculation in the future, I can simply switch the DistanceCalculator implementation, and my application "core" (separate .jar file) will be unchanged.

[Sebastian Gozin]

I agree with Michel that JSON mapping does not appear to fit in the core application module so you shouldn't depend on it.
Basically, your core application can simply use a string type or an array type and your JSON mapper knows how to translate that.
The tricky bit where colleagues tend to have issue with this is JSON annotations which need to be smeared all over the core entities for the JSON mapper to know how to deal with those types.
I don't like that one bit and tend to try and solve that with wrappers or extensions that live in the json support module.

As for libraries like joda-time or guava.
Personally I find these high quality enough to break the rule even though most other modules will expect Data instead of DateTime.