the clean architecture

[Gian Carlo Pace]

A very interesting Uncle Bob's article about architectures:

http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html

WDYT about it?
--
gk

twitter: @gicappa

[Matt Wynne]

On 20 Sep 2012, at 20:53, Gian Carlo Pace wrote:

A very interesting Uncle Bob's article about architectures:

http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html

WDYT about it?

It's good stuff. I like how he's boiled down the common elements between all those patterns.

I'm not personally convinced about the need for a specific Use Case layer. It feels a bit procedural to me to have objects whose job is just to co-ordinate other objects and tell them what to do. I'm trying to find ways to build a domain model that can support lots of different use cases as a whole, just by having a simple message sent into the model at the appropriate point.

I've been reading David West's Object Thinking lately, which has been bending my mind somewhat.

I think layers are over-rated generally. Rails has encouraged us to put everything into categories (models, controllers, presenters, exhibits etc etc) and IMO it's clouded our thinking. Layers are important for managing dependencies as described in that article, but I think that continuing to slice everything along that axis fragments your code and makes it harder to build a cohesive domain model.

I need to write a blog post about this.

cheers,

Matt

--
Freelance programmer & coach
Author, http://pragprog.com/book/hwcuc/the-cucumber-book
Teacher, http://bddkickstart.com

Founder, http://www.relishapp.com/
Twitter, https://twitter.com/mattwynne

[Shane Mingins]

Hey Matt, just quickly, have you read Domain-Driven Design by Eric Evans?  In there he talks about Services which are part of the domain model ... and he distinguishes between application services and domain services.  I just thought what you were describing as your goal:

"I'm trying to find ways to build a domain model that can support lots of different use cases as a whole, just by having a simple message sent into the model at the appropriate point."

fitted with Eric's description of domain services.  Eric in his book describes a Funds Transfer Domain Service which interacts with the Account and Ledger objects.

--
Shane Mingins

[Gian Carlo Pace]

Hi Matt,
thanks for your answer, my comments are inline:

> It's good stuff. I like how he's boiled down the common elements between all those patterns.
> I'm not personally convinced about the need for a specific Use Case layer. It feels a bit procedural to me to have objects whose job is just to co-ordinate other objects and tell them what to do. I'm trying to find ways to build a domain model that can support lots of different use cases as a whole, just by having a simple message sent into the model at the appropriate point.

That is a great point. TBH I used in the past the Use Case objects "pattern" and I found that was a successful solution if you're able to slice the use cases correctly in many small different objects one for each application's behaviour otherwise it becomes just one big procedural place as you said. I think that the good part of UC object is that they help keeping the code expressive and a high cohesion that is something somewhat difficult to achieve while doing TDD.

> I've been reading David West's Object Thinking lately, which has been bending my mind somewhat.

I bought it two weeks ago and I'm just at the very beginning of it right now so I'll get back to you if I change my mind about UC objects :)

> I think layers are over-rated generally. Rails has encouraged us to put everything into categories (models, controllers, presenters, exhibits etc etc) and IMO it's clouded our thinking. Layers are important for managing dependencies as described in that article, but I think that continuing to slice everything along that axis fragments your code and makes it harder to build a cohesive domain model.

I think layers are useful to apply a "dividi et impera" way of writing software. Coming from an interfaces world (like java) makes easier separating things into layers in my minds and apply DIP principle. But here I'm not sure to get what you mean: the domain model in Uncle Bob's view should be contained in one single layer so why do you feel it'd enforce the lack of cohesion?

>
> I need to write a blog post about this.

I'm eager to read it! :)

cheers,
--
gk

twitter: @gicappa

[Matt Green]

Perhaps not every project has a need for use cases. For instance, if you were writing a compiler, what would the use cases be? I don't see many. A rich domain model, yes, but not many use cases. 

One thing struck me as I was reading about use cases: they tend to pull a lot of non-UI, side-effecting code into them, making them impure (to use Haskell's terminology). Meanwhile, your domain model remains pure. The use cases are responsible for manifesting the results of the pure computation into an impure environment. For this reason, I find them very attractive, even if they do elicit some Kingdom of Nouns-ness.

[Gian Carlo Pace]

Hi Matt,

> Perhaps not every project has a need for use cases. For instance, if you were writing a compiler, what would the use cases be? I don't see many. A rich domain model, yes, but not many use cases.

yes I think you've touched a right point. Only a certain type of projects will fit this way of creating software. I think that over the years compilers are a some kind of well known beasts that maybe could be expressed better in a more procedural/modular style - anathema! :) - creating a few steps of processing (lexical analysis, symbol table creation...) but TBH no customer ever asked me to create a compiler and many clients asked me to create a webapp (auction systems, cms, administration webapps) where use cases are the way they express the behaviour of the system (i.e. the user should be able to log in the system specifying a username and a password).

> One thing struck me as I was reading about use cases: they tend to pull a lot of non-UI, side-effecting code into them, making them impure (to use Haskell's terminology). Meanwhile, your domain model remains pure. The use cases are responsible for manifesting the results of the pure computation into an impure environment. For this reason, I find them very attractive, even if they do elicit some Kingdom of Nouns-ness.

I think I've lost you a bit here but it sounds very interesting. Given that I know very few concepts about pure functional languages, could you expand the concept, please?

Cheers,
--
gk

twitter: @gicappa

[Matt Green]

In Haskell, pure code is not allowed to have mutable state. In addition, pure code is not allowed to alter the world (read: have side effects such as file I/O, printing to console, etc), either. This lets the compiler do interesting things with it, in terms of making it parallel. It also lets developers reason about it in a much more strict way. Impure code can call into pure code, but not vice versa.

Most domain models are stateful. But I found the concept that interactors act as 'impure' code calling into 'pure' code more than just coincidental. They shield the domain model from side-effecting operations that change the world around them. The domain model is along a discrete conceptual boundary, and has its own notions of purity: do not rely on any UI, persistence, or other application service. In addition, the interactor is also a degree more pure than the UI, which is subject to very high rates of churn.

Matt

[Brian Knapp]

This is super interesting because it is exactly why in Obvious Architecture I've moved towards immutable entities and as much of an functional/immutable style as possible inside use case objects (which we call actions). The impure parts - DB and IO are passed in as either an input hash, or pluggable data sources that are bound by type checked contracts. 

In my experience so far, by enforcing types and data structures at the boundaries of various layers, it eliminates whole classes of errors and allows for particular assumptions to be made as you code. As a result, the code becomes much cleaner and more straightforward. 

The only downside to this is the ruby community itself. Many ruby people don't seem too fond of contracts, type checking, or non railsy structures. I'm thinking that the clean architecture concepts might actually fit better or be more widely accepted in other languages and communities like Scala, .NET, Java, or maybe Python or Go. If nothing else, some other languages give more of the tools to implement clean architecture out of the box than Ruby does. 

-Brian

[Arne Brasseur]

While I agree that the "Rails mindset" is pervasive in the Ruby
community, certainly here in Europe I find many people are interested
in a more "plain Ruby" approach, augmented with practices from
functional programming.

The ROM project, the successor of DataMapper, is a good example. It
provides an alternative to ActiveRecord but based on the data mapper
pattern, so your models can be simple POROs. It's built from the
ground up on immutable objects, and hence most methods are simple
value-in value-out. The same people also made the IceNine gem which
makes it easy to freeze entire object graphs.

They use elaborate YARD documentation throughout their projects,
documenting the types that go in and out. While this is no substitute
for actual type checking, it certainly helps while coding to have this
implicit contract.

> --
> You received this message because you are subscribed to the Google Groups
> "Objects on Rails" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to objects-on-rai...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.