Has anyone done DCI with ruby?

[Grant Petersen-Speelman]

Hi All

So I really like the idea of what DCI offers.

I am thinking of getting the clean-ruby book but wanted to see what others think of it first.

Here is someone's implementation of it http://dci-in-ruby.info/

Has anyone seen this kind of implementation in the wild? Anyone else like how it look/works?

Open to any thoughts really.

Grant

[ivor...@gmail.com]

Hi Grant

My experience with what I think you are referring to was in the context of a rails 3 application. I'm not 100% sure I am answering your question though.

I used concepts of separating the logic that related to specific events out of the models that were involved. I moved them into what I called commands, builders and queries. They were essentially the same concept for different applications. Since they did not slot into any of the existing rails MVC structures they were super easy to test - no magic, just straight-up ruby objects. They also made testing the models and the controllers in my rails app super easy, since both had very little left to do. 

An added bonus of having clearly defined and tested ways to do certain things in my app was that I could use them in my tests - such as setting up data for integration tests. 

This post http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ and POODR by Sandy Metz were the inspiration for this changes for me. The "Clean Ruby" book looks good. Thanks. I'll get my hands on it. 

I think https://github.com/apotonick/trailblazer also applies some of the DCI concepts to rails. 

If it seems like I am smoking my socks and completely missing what is happening here, please let me know. I wouldn't mind learning what I am getting completely wrong here :)

Cheers!

--
You received this message because you are subscribed to the Google Groups "Cape Town Ruby Brigade" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cape-town-ruby-br...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Grant Petersen-Speelman]

Thanks for the response. Maybe my question was a bit too broad :)

Maybe more specific, DCI has this idea of a Context, which I like to think of as a Command but all the code required to complete it is in the context.

So basically you have one class and everything you need to know on how it gets its job done is in the same file.

If you look at this EG https://github.com/vsavkin/DCI-Sample/blob/master/app/contexts/bidding.rb, 

you will see the validation code is in the context as well and not on your models.

Also what I find very interesting is the the objects you pass in gains a role, it does this by extending the object. (look at line 23)

What are your thoughts on that?

To unsubscribe from this group and stop receiving emails from it, send an email to cape-town-ruby-brigade+unsub...@googlegroups.com.

[Wilhelm Kirschbaum]

Defining a final design or organising structure is not very useful imo. I can’t judge the final design without seeing how they got there. The problem is that the commit history does not look healthy. it feels like upfront design, moving away from agile concepts. this makes me have a negative bias towards DCI.

I think it might eventually lead into worst code than just following the basic principles. its confusing. i can see what they are trying to do, but its setting boundaries/rules. The quickest introduction i can think of to "basic principles" is Corey Haines' book about the Four rules of Simple Design.

[ivor...@gmail.com]

I really like the idea of separating the repository from the logic. 

Again, speaking in a rails context, traditionally, for example, the registration code would sit in the user model. But this sucks in two ways. One, this makes involving any other models in the registration process messy. Two, it litters the user model with registration code that is actually only relevant when the user is first created. 

Also, if there are different types of users that need registration then you need conditional logic in your user model to apply particular validations and hooks. 

Just some thoughts. 

On Wed, Aug 26, 2015 at 10:33 AM, Wilhelm Kirschbaum <wkirs...@gmail.com> wrote:

Defining a final design or organising structure is not very useful imo. I can’t judge the final design without seeing how they got there. The problem is that the commit history does not look healthy. it feels like upfront design, moving away from agile concepts. this makes me have a negative bias towards DCI.

I think it might eventually lead into worst code than just following the basic principles. its confusing. i can see what they are trying to do, but its setting boundaries/rules. The quickest introduction i can think of to "basic principles" is Corey Haines' book about the Four rules of Simple Design.

--
You received this message because you are subscribed to the Google Groups "Cape Town Ruby Brigade" group.

To unsubscribe from this group and stop receiving emails from it, send an email to cape-town-ruby-br...@googlegroups.com.

[Wilhelm Kirschbaum]

You don't need a set structure to do that though. as example for registration:  add a file to lib/user_register, instantiate it with a aggregate root/repository/active record model. In the controller write UserRegister.new(User).save!

Rails model is a repository, nothing more. rails controller is an http endpoint, nothing more. imo the application itself should not be dependent on a rails structure or any rails libraries. This is currently very easily possible when starting with a vanilla rails app.

Make sure the app part (lib folder) follows some basic design principles and not much can go wrong. Limit integration points and stop using magic rails magic, its not worth it, keep it simple.

[ivor...@gmail.com]

I couldn't agree more. I guess I am not really seeing the difference between what you are describing and DCI (mostly because I am not clued up on DCI then). 

Either way, I really like your approach here. 

--

[Wilhelm Kirschbaum]

:) I think the difference is that DCI is more complex to explain and harder to remember. It does not show me the reasoning.