You're welcome :) You might appreciate the original book more: http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215
It's much better written than "Quickly DDD". Regards -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Daniel Soto Sent: den 28 mars 2009 18:28 To: [email protected] Subject: RE: business objects in Monorail Thank you so much for your very complete answer!! I will read the book that Marcus recommended. Regards. El vie, 27-03-2009 a las 22:46 +0000, Henrik Feldt escribió: > Hi Daniel, > > When you're doing a new project, it's quite easy to map the domain > objects directly to the database. The domain entities, however, > contain on top of their data, also logic and methods which make them interact > with each other. > On less than Greenfield projects, it might take some creative mapping > to get as clean domain layer as possible (like event listeners, custom > types and one-to-one mappings). > > There aren't only entities (see the book Markus referred to), in the > business layer, but also value objects (e.g. the money pattern) and > domain layer services (which interact across 2..* entities) or even > what can be more thought of application services which further can > performs things like workflow invocations, invocations to other > systems etc along with infrastructure-calls, such as making sure > logging works, or providing a nice façade in front of the domain > objects for consumption from a soa-service (aka something ~WS) or a WS or > simply the GUI of your application. > > In a sense the MVC pattern is very good for modeling applications > without much interconnect; in the 'classic' version, the model in some > sense interacts with the views by pushing events/allowing subscribers. > Personally I prefer something along the castle lines with more dumb > (passive) views, taking instructions from the controllers. > > Depending on what stage you're at in the application dev you can > either put a lot of what I above described as domain/application > services in the controllers; this is probably the quickest, but as you > start expanding the application with more interconnection features > (consumption over LAN, WAN, Flash), you might benefit from moving lots > of what you previously had in the controllers to application services, > making the controllers rather into something which listens to events > from the business layer/tells the application what views to show and > simply validating and parsing the input so that your application is safe from > malicious input. > > The application services and domain services are close in definition > and seem to fit what you're calling the "Sales" object (depending on > what you had in mind). By naming convention ISomethingService, we know > approximately what the service responsibilities are (and are not), > while a simple naming of "Sales" might cause some confusion... :P > > Finally, the * services can often be incorporated into your domain > layer with creative use of aspects and concerns. Qi4j (Qi4j.org) uses > this technique and I've seen presentation where it's recommended as > well. I haven't seen that many examples (very few in fact) which use > this, and making sure it all works with your ORM of choice (say NH), > can be tricky if that, too, uses method interception via some dynamic > proxy; perhaps Ayende or Hammett can give you (and me) some further > advice on how they would do such as thing :p (hint hint). > > Markus talked about having different objects in data, business and gui > respectively: this may or may not be the way to go. In DDD Eric > discusses how the business layer over time becomes more of an abstract > layer where consuming upper layers provide the concrete > implementations. Also DTOs (the objects in the GUI): data transfer > objects are common when you have complex business entities; again, > depending on your application, you may have custom DTOs which > selectively show parts of your business objects to services (which > e.g. other companies consume) -- this improves the problem of possibly > leaving a field as [NonSerializable] when you expand, but also allows > you to map something simpler as the output of the service (if you > expose it like that). Normally though, it's quicker and much easier to > simply use the business entities in the GUI-layer. I haven't seen many > "data" objects though, but maybe he means the "abstraction" of the DB such as > TableRow which might be hidden in e.g. NHibernate or some other ORM. > > Cheers > Henke > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Daniel > Soto > Sent: den 27 mars 2009 18:53 > To: [email protected] > Subject: business objects in Monorail > > > Hello. > > Sorry for the newbie question. > > According to MVC pattern, the model are all business objects in a MVC > application. In many examples that I see, the model matches exactly > with the database model (1:1 relation). > > Can have other business objects in the model, without break the MVC pattern? > > For example: A database model have two tables, Product and Customers, > and they generates two classes with same name in the model, but it's > possible that in the model have a third class named Sales, which do > some special process over Product and Customers classes, but not > necessarily matches with some table named "Sales" in the database. > > It's possible this? > > Thanks! > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en -~----------~----~----~----~------~----~------~--~---
