A good starting point is read Eric Evan's "Domain Driven Design", you will probably learn a lot about how to organize big systems in any language. The book is easy to read and has examples in Java.
- Maurício Linhares http://alinhavado.wordpress.com/ (pt-br) | http://blog.codevader.com/ (en) On Wed, Feb 4, 2009 at 3:45 PM, Kim Shrier <k...@tinker.com> wrote: > > Hello Seb, > > An approach that I have used is to place the higher level business > logic in model objects that do not inherit from ActiveRecord. In > the way I think about larger systems, the higher level business > logic is still part of the model. The model is not limited to > managing the persistence of state. I don't have a formal way of > organizing these subsystem model objects as I haven't tackled any > projects that sound as extensive as what you are working on. > > HTH > Kim > > On Feb 4, 2009, at 11:28 AM, sbrocher wrote: > >> >> Hi Julian, >> >> Thanks for your answer. I've seen Datamapper before. However, the way >> I understand it, Datamapper is pretty much just a replacement for >> ActiveRecord, so I don't see how it would add the extra layer of >> abstraction I'm searching for... Did I miss something here? >> >> Thanks >> Seb >> >> On Feb 3, 9:33 pm, Julian Leviston <jul...@coretech.net.au> wrote: >>> Datamapper. >>> >>> Blog:http://random8.zenunit.com/ >>> Learn rails:http://sensei.zenunit.com/ >>> >>> On 04/02/2009, at 1:59 PM, sbrocher <sbroc...@gmail.com> wrote: >>> >>> >>> >>> >>> >>>> Hi, >>> >>>> I've implemented a few big RoR apps. I do have some good experience >>>> building large systems in many different languages and platforms >>>> but I >>>> don't consider myself a RoR guru, so I'd like you experts comment on >>>> my thoughts. >>> >>>> I'd like to divide a large system (app) into several functional, >>>> high- >>>> level sub-systems. These are higher level than rails Models, and >>>> provide APIs that implement business logic around functional groups. >>>> Examples of these are billing manager, security manager (accounts, >>>> privileges, roles, etc), inventory manager, manufacturing manager, >>>> and >>>> such (of course, these are just examples, but you get the point). >>> >>>> These high-level sub-systems may be implemented as servers (think >>>> SOAP / REST / XML-RPC / ...), or just plain Ruby classes. Some of >>>> these sub-systems implement integrations with other systems, for >>>> example, a credit card gateway, an accounting system, Fedex, you >>>> name >>>> it. Some of the sub-systems may be just proxies to a system >>>> implemented on some other technology. >>> >>>> The user interface (views) would not have access to any of the >>>> Models. >>>> They just present and / or grab data that is prepared for them / >>>> pushed back to the controllers as local variables / arrays / hash >>>> tables that don't reflect an actual Model. >>> >>>> The controllers do not have access to Models either. Instead, they >>>> call methods from the high-level functional sub-system APIs. >>> >>>> The Models implement lower-level business logic related to how to >>>> the >>>> information is stored and retrieved from the database, the pertinent >>>> validations, associations, etc. but do not implement high-level >>>> business logic such as "how do I bill Joe for a specific event that >>>> results in the combination of many other parameters and variables >>>> that >>>> at the end come from diverse fields on many different tables on the >>>> underlying database structure". >>> >>>> The high-level sub-systems all share the same database and therefore >>>> same data model and only communicate with each other via their APIs, >>>> and can access all Models directly. >>> >>>> In other words, this would work more or less as a new layer in >>>> between >>>> the MVC pattern: >>> >>>> view <-> controller <-> high-level sub-system <-> models <-> >>>> database >>> >>>> The idea is to build the app in a more robust / less coupled way >>>> where >>>> I can exchange parts of the app by different technologies and other >>>> applications in the future without having to recode a bunch of >>>> things. >>>> For example, the security subsystem could one day be replaced by an >>>> AAA server and then the subsystem would be re-implemented to call >>>> the >>>> AAA server (to replace its own original implementation), however the >>>> rest of the app would continue to use the same API calls to the >>>> security subsystem and so the change is isolated from the rest of >>>> the >>>> app. >>> >>>> The problem with this is, I'd loose many of the RoR goodness, such >>>> as >>>> form helpers, easy models validation thrown back to the interface, >>>> etc. >>> >>>> Am I missing some Ruby language construct or RoR framework construct >>>> that would enable me to implement this kind of design on an easier >>>> manner? Should I instead be thinking of many RoR applications >>>> somehow >>>> talking to each other? >>> >>>> I really like RoR but I'm starting to find myself on a tough >>>> situation >>>> dealing with evolving mid-to-large systems (think 50+ database >>>> tables >>>> and 8+ sub-systems). I need to come up with a pattern that would >>>> force >>>> me to implement and design code that works and is maintainable on a >>>> long-term vision, however I'm not sure if this is because I don't >>>> know >>>> the 100% of what the language and framework has to offer, or if I am >>>> just using it the wrong way (or both? :-). >>> >>>> Comments? >>> >>>> Thanks, >>>> Seb- Hide quoted text - >>> >>> - Show quoted text - >> > >> > > -- > Kim Shrier - principal, Shrier and Deihl - mailto:k...@tinker.com > Remote Unix Network Admin, Security, Internet Software Development > Tinker Internet Services - Superior FreeBSD-based Web Hosting > http://www.tinker.com/ > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
