2 Replies Latest reply on Oct 8, 2010 6:42 AM by Marcelo Marmol

    Cairngorm 3 responsabilities

    Marcelo Marmol

      Ok, I am having some doubts about packages, for what i have read over the wiki application should be used for command and events, and controllers should be at infrastructure. But looking at the examples I see that everything is put over application, and going to the web for examples things can get more confused... So how did you guys are doing it in real life projects?



        • 1. Re: Cairngorm 3 responsabilities
          Alex Uhlmann Level 3

          Hi Marcelo,


          I'd say packaging is more important on a higher level, on the functional area than on architectual layers.  Packaging on functional areas (checkout our guidelines on that in modularity) can prevent centralizations, and encourage developers to think more about the dependencies between functional areas.


          But you're right in pointing out that our guidelines here are a bit confusing (i.e. with putting Commands inside infrastructure and then placing Commands inside the application package of the samples).


          As our references show in some guidelines, we've tried to follow Eric Evan's Domain Driven Design definition. Below are some quotes:


          Application Layer:


          Defines  the jobs the software is supposed to do and directs the expressive  domain objects to work out problems. The tasks this layer is responsible  for are meaningful to the business or necessary for interaction with  the application layers of other systems.


          This  layer is kept think. It does not contain business rules or knowledge,  but only coordinates tasks and delegates work to collaborations of  domain objects in the next layer down. It does not have state reflecting  the business situation, but it can have state that reflects the  progress of a task for the user or the program.


          Infrastructure Layer:


          Provides  generic technical capabilities that support the higher layers: message  sending for the application, persistence for the domain, drawing widgets  for the UI, and so on. The infrastructure layer may also support the  pattern of interactions between the four layers through an archtectual  framework


          Usually  I find that infrastrcuture code is often extracted into code libraries  that are shared either by all or a number of functional areas. This is  theefore often very important code as many parts rely on it. It needs  special attention on change control and quality.


          Note  that this is a guideline, not an enforcement. This separation only  makes sense on a particular scale. i.e. if your functional area only contains 5 objects, you might just drop the last packaging by architectual layer. It is separation by type, not  functional cohesion so we need to be careful not to divert to much from  OOD practices.

          • 2. Re: Cairngorm 3 responsabilities
            Marcelo Marmol Level 1

            Ok, great reply Alex, was really helpful. After expending some days using Cairngorm libs for real life project things got more clear.