Oh, I was by no means sorry about the post itself J, I was more or less apologizing for reposting it (to those who have already read it on Nabble).
Anyhow, in effect that is kind of what I am striving for is to make a simple application (for learning purposes). However, I am still a little fuzzy on the structure of the whole domain driven design concept. I am reading lots about it, and am more or less using this forum for a little verbal diahrea as I am going through this learning venture. I am of course doing what everyone else is doing (well every newbie around here at least), and building a simple CMS as my starting point. Because my main purpose behind using / learning the Zend Framework is for web based applications in the long run, and some would argue that websites are not the best use of Zend Framework, I have always loved programming in PHP, and am always learning new things with it, I have a hard time working with content management systems that are available today. Every one of them seems quite restrictive in its own way, and reading someone elses code to try to decipher how they developed it really sucks. It is amazing how these relatively complex CMS systems available today (Joomla/Drupal/etc) are even functional considering how non-logical the application was written. I have been working with Zend Framework now since about v1.0 (I got to miss the whole pre-release candidates to version one whew dodged that bullet). I was really cool with how things were going around version 1.5. Then all hell broke loose (for how I thought about development/design) with the introduction of Zend_Tool and Zend_Application. Zend_Tool, in itself was relatively easy to grasp, it was and is still quite simplistic in its default form, I havent gotten into expanding its functionality yet (havent found a need really). So the biggest thing I find helps with learning Zend Framework is to use everything in its default context as much as possible (while learning the component), ie: Rather than extending Zend_Form (creating my own extended class), I start by creating a form in the controller $myForm = new Zend_Form(); $myForm->addElement(blah blah); etc. I do nothing fancy. I pass it to the view, and render it. Then I look at the source (ctrl-u -> firefox), and see WHAT just got rendered. Then I add CSS and make it look fancy. Obviously the best method is not to have all that garbage in your controller (or at least that is what I have learned), then I will move that code into a class (or extend the Zend Form class), leaving it completely basic, then I will add the extra goodies (validation, filtering, etc). That is my thought process when it comes to learning Zend Framework itself. I also read a lot of posts here, blogs, tutorials, etc and just keep playing with it. I am still almost completely lost with Zend_Application at this point, I kind of understand the Bootstrap class (as I have used bootstrapping forever), however not quite the way Zend Framework uses it (by default). So now I am trying to wrap my head around Zend_Application as well, but all in time, I am at least picking up some of it. I find the API documentation is a great source as well. Especially when something isnt working quite the way I *THINK* it is supposed to work. I have browsed the source of Modx (www.modxcms.com) which has given me a few ideas here and there. I even tried to install Cahaya (another new CMS built on Zend Framework), but that one crashed and burned for me and I dont really like the directory structures the developer used, so I havent even started looking at the code on that one, it has me afraid already J ) But mostly where I am at right now is getting to the point of developing a solid architecture and layout that I can build on, so I am really trying to understand everything I can about DDD and PoEAA. (I bought PoEAA, and I have the Domain Driven Design Quickly version of Eric Evans book I will most likely be rushing out to buy the full version of his book soon too). I also have to say I picked up Rob Allens book Zend Framework in Action, however I bought that one a little too late. Being a huge fan of Robs tutorials, I recently picked up his book (have been meaning to forever). Unfortunately it was published around version 1.5 and therefore misses most of what I am learning right now (Zend_Application). Kudos to the book though, very well written Rob! I have numerous other projects that I am really interested in kicking off as well, I just decided a simple CMS would give me a fairly generic and well rounded understanding and learning base to kick off some of these other more advanced projects I have in mind. Thanks Aaron From: Diego Potapczuk [mailto:potapc...@gmail.com] Sent: September 24, 2009 8:01 PM To: Aaron Murray Cc: fw-general@lists.zend.com Subject: Re: [fw-general] Domain Driven Design / Patterns of Enterprise Application Architecture [repost] Don´t be sorry for sending a quality post like this, this is an area that i feel the Zend Framework need a better working to define the best or appropriated way to architect an system build with it. Maybe you could make an simple application to show how all it would work together, especially joins tables and such. ::: Diego Potapczuk On Thu, Sep 24, 2009 at 10:42 PM, Aaron Murray <ajmurra...@gmail.com> wrote: Hey everyone, Sorry about the repost (most of you probably havent seen it as I posted it on Nabble, and of course realized that it didnt get sent because I didnt have a subscription to the mailing list (cancelled it because I was reading everything on Nabble). Anyhow, I am reposting the message now that I have re-subscribed to the list, so it will get some exposure beyond Nabble. I have just gone through an article "Model Infrastructure" -> http://weierophinney.net/matthew/archives/202-Model-Infrastructure.html A most excellent insight on Zend Framework and Domain Models (Matthew you are my hero!) The comments in the article brought me to a slide show "Zend Framework Workshop, DCP09" -> http://www.slideshare.net/weierophinney/zend-framework-workshop-dpc09 An even better, and more up to date insight (Matthew I bow down to your greatness). // on a side note: I love all you guys/gals who have contributed and made Zend Framework what it is today (and what it will be tomorrow) ---- Ok enough rambling, on to nitty gritty. In the first artcle, we are building a model, using a Gateway pattern. The model itself extends Zend_Auth (brilliant, but not necessarily what you are supposed to be doing with light weight models). I poked through the Patterns of Enterprise Architecture / Martin Fowler. In the book, he refers to the gateway pattern being the pattern of choice due to its ease and flexibility. Reading through the comments in the article, I came across the second (and newer/different) ideals by using a DataMapper pattern in replacement to the gateway pattern. I then started reading up on the DataMapper pattern. I like both patterns, both are very functional. However I did get a little confused. The first thing I am a little confused about: My logic is that we have a data source (be it a database table, a web service, a file, etc). Now according to PoEAA, a service is the 'business logic' of the application. However, Matthew places a service between the Controller and the DataMapper. (Makes sense to me). On the other hand I also see services as being the layer between the DataMapper and the DataSource. (For example we have "Zend_Service_Amazon". Is that not something we could/would layer between the DataMapper and the DataSource (being Amazon). (Forgive me if I am wrong, I really haven't worked with that 'service' yet, I am just throwing out an example). So if that *is* a service, then by my logic: App_Model_DbTable_User extends Zend_Db_Table_Abstract (in the slideshow) *should* really be App_Service_DbTable_User extends Zend_Db_Table_Abstract because in my logic, the layer between the DataMapper (App_Model_User_DataMapper) and the DataSource (The database table) is a service, and in this case is an extended class of Zend_Db_Table_Abstract In saying that, here is how I envision the structure: |--> /models | |--> User.php (Default_Model_User implements Zend_Acl_Role_Interface) | |--> Article.php (Default_Model_Article implements Zend_Acl_Resource_Interface) | |--> /services | |--> User.php (Default_Service_User) | |--> Article.php (Default_Service_User) | |--> /User | | |--> DataMapper (Default_Service_User_DataMapper) | | |--> DbTable (Default_Service_User_DbTable extends Zend_Db_Table_Abstract) | | | |--> /Article | |--> DataMapper (Default_Service_Article_DataMapper) | |--> DbTable (Default_Service_Article_DbTable extends Zend_Db_Table_Abstract) So in my vision, the /models stays fairly clean, contains basic properties and no business logic at all (however may contain behaviors that manipulate the data/properties themselves). The service contains the business logic (create, login, save, etc) and would have the ability to create new objects (without id's say in the case of the User). The DataMapper handles the actual 'creation' of the User/Article object (as it comes from the database (or other data source)). I am not altogether sure where the best placement of the DataMapper is because it deals with a model it could go in the model directory structure, but it also deals with the data source (which as I stated to me feels like a service), so it could go into the service directory structure. If my thoughts on this are out of line, please correct me. The other thing I was thinking is that I should have a contract (implements) for the DataMapper class which defines the requirements of the data mapper. For example the service will want to call functionality of the data mapper in order to do things. Lets use 'save' as an example: $user = (an instansiated modified Default_Model_User object loaded from the database) $userService->getDataMapper()->save($user); Now within the DataMapper object we have a method called save, which contains the logic to call the Zend_Db_Table_Abstract class (Default_Service_User_DbTable in my case) Now lets say we want to use a different data source. The new data source has a different api to work with data. No problem, we create a new (or modify existing) DataMapper. The save function in the new / modified data mapper, makes the appropriate calls to the api, and appropriately saves the data to the new data source. The problem that could arise, maybe we decided to call the 'save' method as 'wHey everyone, Sorry about the repost (most of you probably havent seen it as I posted it on Nabble, and of course realized that it didnt get sent because I didnt have a subscription to the mailing list (cancelled it because I was reading everything on Nabble). Anyhow, I am reposting the message now that I have re-subscribed to the list, so it will get some exposure beyond Nabble. è
