Lots of good discussion here. The big question is where your business logic goes. ADM is an approach where the data contructs (beans/domain model) are operated upon by methods in your service layer. Here the domain objects are often called "dumb data holders" that don't really have any behavior associated with them because all of that behavior is in your service methods. Many disagree with this approach because it separates your data from its behavior, whereas one of the main goals of the OOP movement was to tie the two together. Put bluntly, ADM can lead to very procedural code, described briefly in Fowler's Transaction Script pattern:
http://martinfowler.com/eaaCatalog/transactionScript.html I'm sure that everyone in this list would agree that there are benefits to coding in an OO style vs. a procedural style, but using an OO language (or in CF's case, it's OO contructs) doesn't mean that you can't still design an app that is very procedura in nature. And if that's where we end up then it's very possible that many of the benefits of the OO approach have been lost. In a Rich Domain Model, behavior lives in your domain objects, right alongside your data. You still have DAOs that are responsible for handling persistence, but I think they should be transaction-ignorant. The Service Layer orchestrates the RDM and DAOs and is concerned with transactionality. You can do really cool stuff with AOP here. The SL is also the interface that is exposed to the "client" which for web apps would be the controller if you're using MVC. So the SL wraps the business logic and persistence layers and hides all that complexity from the client. I would argue that the SL's interface should be use-case driven. That way, the SL methods map very closely to use-cases in the application, but may involve a series of methods calls in the RDM or DAO layers. This way, the SL functions just like a Facade (hiding complexity of internal implementation) which would be the other term that is commonly used to describe the SL. One other advantage of this layering approach is testability. You can test your RDM, DAOs and SL in isolation from one another quite well. If most of your logic is tied up in your SL then it becomes harder to test, which will likely lead to poorer quality code, and your customer will definitely notice (and care) about that. Now, with all of this being said, I think there are many tools available in the Java world that simplify this style of implementation considerably. I'm not 100% sure if CF is quite there yet. Frameworks like ColdSpring and Reactor are going a long way to fill in gaps in the Model since most previous frameworks were dealing exclusively with MVC. I haven't worked with them enough to say for sure but I've been very impressed with what I've seen. If you're a fan of computer books then you might want to check out these two: http://domaindrivendesign.org/book/index.html http://www.martinfowler.com/books.html#eaa The best part is that they don't focus on a particular platform or language. So whether you're doing CF, Java, .NET or anything else they should come in handy. Good luck :) -Cliff ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
