# Structuring larger RoR projects/systems **URL:** \ **Category:** Rails\ **Created:** [February 8, 2008, 10:53pm UTC](https://www.ruby-forum.com/t/structuring-larger-ror-projects-systems/128565 "2008-02-08T22:53:57Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![jarikoister](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/b38774/32.png) [@jarikoister](https://www.ruby-forum.com/u/jarikoister)\ **Post date:** [February 8, 2008, 10:53pm UTC](https://www.ruby-forum.com/t/structuring-larger-ror-projects-systems/128565/1 "2008-02-08T22:53:57Z")
Hi, I am considering using RoR for a quite sizable project involving 10-15 developers. I am very experience with other technologies such as Java and C++, and I would know how to structure a system so that different developers can work with different parts of the system without stepping on each others toes. In Java I could use eclipse and have different projects for the DAO, the application layer, the web layer, etc etc. With MVC model in RoR and the way RoR projects are structured I am a not sure how to structure a project. Clearly I certain Ruby components could be separated out in separate projects. What are the common ways that larger projects have been structured to facilitate effective development (turn around leveraging the MVC model) and at the same time separating system structures into manageable pieces. Thanks a lot of any feedback, and sorry if this was the wrong forum. But I did not see any on more general applications engineering. Regards Jari K. ---
**Author:** ![jarikoister](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/b38774/32.png) [@jarikoister](https://www.ruby-forum.com/u/jarikoister)\ **Post date:** [February 9, 2008, 12:13am UTC](https://www.ruby-forum.com/t/structuring-larger-ror-projects-systems/128565/2 "2008-02-09T00:13:21Z")
On Feb 8, 2008, at 1:52 PM, jarikoister wrote: > pieces. > > Thanks a lot of any feedback, and sorry if this was the wrong forum. > But > I did not see any on more general applications engineering. > > Regards > Jari K.z It’s easy to write an application that won’t scale using pretty much any technology. In particular, the more complex the configuration and layering, the more opportunity (IMO) for a tight coupling that won’t scale out well. Alternatively, you can use a shared-nothing architecture and scaling out becomes a far easier task. Many enterprises don’t need scaling in the sense of handling millions of pageviews a day so be sure you have a problem before you identify scalability as a criterion. In terms of development team structure, this will take some getting used to. ThoughtWorks is putting teams onto enterprise Rails projects to good effect, so they might be a good consulting resource if you get hung up on this. If I were setting up a team, I would make the cornerstones of development: 1. Spec first, code later. That way it doesn’t so much matter who does the implementation so long as the behavior is described accurately 2. Create business-relevant user stories. 3. Identify thin vertical slices and implement these in your iterations. 4. Only use developers who are comfortable with distributed source- code control (like Subversion). Rails is pretty darn opinionated about what parts of the application logic belong where. You can make changes to suit your needs, but at the end of the day, what’s in Rails, and really fire-tested is the three-tier model-view-controller pattern where the model handles both database communication and business logic, the controller handles glue between model(s) and views, and the views are the presentation layer. You can add layers (like presenters) but right out of the box, the separation of responsibilities is pretty easy to grasp and new developers brought onto the team who have Rails experience will understand your code pretty quickly. I don’t know anything about your business needs, but if you have any doubts about Rails’ ability to do the job, find a consultant with a portfolio of clients similar in size to your company. Hire them to write a whitepaper on the pros and cons of using Rails to solve a particular problem (including specifics of traffic, security requirements, time-to-develop, maintenance costs, labor pool, etc.). Getting a professional with this kind of experience to provide you a technology assessment will provide a recommendation from an expert with known qualifications and very likely would begin a business relationship between you and that company as you bring your team online. I mentioned ThoughtWorks because they have a good client portfolio. There are a number of other, smaller companies who could be even better positioned to provide the information you need. This would be my reply in general to anyone who is interested in Rails for your enterprise application. Hire a pro. Pay that person or small team well to spearhead your effort. ---
**Author:** ![jarikoister](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/b38774/32.png) [@jarikoister](https://www.ruby-forum.com/u/jarikoister)\ **Post date:** [February 10, 2008, 1:30am UTC](https://www.ruby-forum.com/t/structuring-larger-ror-projects-systems/128565/3 "2008-02-10T01:30:59Z")
Jari, If your team is already familiar with Eclipse, I would took into the Aptana plugin for Rails (formerly RadRails). As mentioned, it’s an Eclipse plugin that’s Ruby and Rails aware so it provides nice syntax highlighting, subversion and CVS integration, integrated Webrick and Mongrel servers, etc. Personally I prefer the RoR-aware netBeans 6.0, but Aptana might be a better solution if your team is already used to Eclipse. The MVC architecture probably maps fairly well to the type of structuring that you are used to, with the exception that you might keep the entire application in a single project. The application/ business layer should correspond very closely to the Model tier. The web layer is primarily the View/Controller tiers. (Note: there is no DAO per se, since the Rails opinion on DAO was to use the ActiveRecord pattern in which a DB row is wrapped in an object that understands how to persist the data). Rails 2.0 offers an additional structuring option. If you are able to break your application down into logical subsystems you could develop each subsystem as a separate Rails application. This might allow you to use smaller teams of 2-5 developers who can closely collaborate on a specific aspect of the application. Make sure that these subsystems use the Rails-standard REST interface. With that you can create a ‘top-level’ web application that makes heavy use of ActiveResource, This application is UI-only, retrieving the necessary data from each of the subsystems through ActiveResource. Your main UI (weblayer) team works here. I have one project that is working on a structure like this and it’s working farily well. One of the great advantages of it is that you may be able to re-use one of the subsystems (e.g., Billing & Financials) for other applications – not just reuse the code but actually using the deployed subsystem. HTH, AndyV ---
**Author:** ![jarikoister](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/b38774/32.png) [@jarikoister](https://www.ruby-forum.com/u/jarikoister)\ **Post date:** [February 13, 2008, 10:30am UTC](https://www.ruby-forum.com/t/structuring-larger-ror-projects-systems/128565/4 "2008-02-13T10:30:06Z")
AndyV, > like this and it’s working farily well. One of the great advantages > of it is that you may be able to re-use one of the subsystems (e.g., > Billing & Financials) for other applications – not just reuse the > code but actually using the deployed subsystem. sounds great - could you please give me some more details - keywords, tips, hints - especially (if possible) where to look for advice, tutorials, examples and/or howtos? Any help would be most welcome 😉