http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660In this instance, it is just playing with routing, building them dynamically based on conventions http://ayende.com/4077/feature-by-feature#comment27http://ayende.com/4077/feature-by-feature#comment27Sat, 25 Jul 2009 16:29:36 GMTVery interesting! I've been using something very similar, but have not found a good way to develop my aspx files & images in the feature project. Could you elaborate a bit on how you do this? Where are the aspx files for your feature at runtime? Do you have a post build event / nant task that copies all feature pages to a specific location beneath your web app? Are they embedded? From the looks of your project icon, you are using a class library or custom project type. How are you getting around Visual Studio hiding the aspx item template for your project? Thanks, Jonathan http://ayende.com/4077/feature-by-feature#comment26http://ayende.com/4077/feature-by-feature#comment26Fri, 24 Jul 2009 20:42:06 GMTThanks again Matt! I believe I need to read up on bounded contexts because that seems to be the main thing that's not clear to me (the implementation not the concept). Thanks for providing a direction for me to research further. Scott http://ayende.com/4077/feature-by-feature#comment25http://ayende.com/4077/feature-by-feature#comment25Fri, 24 Jul 2009 17:48:40 GMTScott - As always, the answer is "it depends". In a large distributed system different bounded contexts often have their own data storage, and their own domain models. Pub/sub is used to handle business events that are being published by the different bounded contexts such that subscribers are able to receive those messages and act on them in a manner appropriate to their context / domain model. The notion of an order might exist in many contexts, but everyone has their own interpretation of what it means to them. If you are building a big system this introduces complexity up front but makes it much easier down the road. If it's a small system you might not want to go this route. For your Track renaming scenario you could be storing all the data in the same database / tables, just using pub/sub to enable async behavior in your system - "TrackRenamed" is published, and the Playlist context/service/etc... subscribes to that and starts renaming tracks contained in playlists (assuming they're stored in a denormalized fashion to make reads fast, otherwise if it's just a foreign key relationship the track is already renamed :) Later on down the road when you have another part of the system interested in that event it's simply a matter of adding another subscriber for that message type. http://ayende.com/4077/feature-by-feature#comment24http://ayende.com/4077/feature-by-feature#comment24Fri, 24 Jul 2009 17:12:48 GMTThanks Matt, That sounds like a completely different world than I'm used to. I take it that the database is highly denormalized then? Duplication of data in the database always seems like quite a headache. So pub/sub would mean that if a band renamed a Track, pub/sub would dispatch an event that this happened, and any publishers (eg: Playlists and their tracks) would subscribe to this event a rename their tracks accordingly? Scott http://ayende.com/4077/feature-by-feature#comment23http://ayende.com/4077/feature-by-feature#comment23Fri, 24 Jul 2009 15:30:21 GMTIt reminds me CAB the first time I saw it. But how do we address the required distribution for windows / smart / RIA / Client Ajax applications? We would still need to fit in some sort of a distribution and features would be splitted atleast for the UI (& its surrounding patterns). Intrestingly, all these looks like lean SOA, just binded to a single platform :). http://ayende.com/4077/feature-by-feature#comment22http://ayende.com/4077/feature-by-feature#comment22Fri, 24 Jul 2009 06:47:57 GMTScott - This is a possibility, but the more likely scenario is that you actually have different tables for each of your contexts. How you store the data and what data you store is unique to each context. So yeah - keep it simple, map one domain model class to a table, accept the fact that some data will be duplicated across bounded contexts, and lean on pub/sub to keep everything in sync. http://ayende.com/4077/feature-by-feature#comment21http://ayende.com/4077/feature-by-feature#comment21Fri, 24 Jul 2009 06:05:46 GMTHi Ayende, I'm probably a bit off-topic but I was curious if having multiple Domain classes mapped to the same table is how you implement a bounded context? I think I've struggled with ORM because I still think data-centric and pretty much map one Domain class to a table. Thanks, Scott http://ayende.com/4077/feature-by-feature#comment20http://ayende.com/4077/feature-by-feature#comment20Fri, 24 Jul 2009 03:11:03 GMTHah. Not to speak poorly of the academics in the room, Patrick. ;) Maybe I overstated. I mean only that I've found I can still separate code without necessarily having an assembly for each little thing. http://ayende.com/4077/feature-by-feature#comment19http://ayende.com/4077/feature-by-feature#comment19Thu, 23 Jul 2009 23:29:02 GMTReading things like... >Anything else is just academic. ...makes me sad :o/ http://ayende.com/4077/feature-by-feature#comment18http://ayende.com/4077/feature-by-feature#comment18Thu, 23 Jul 2009 18:57:12 GMTAyende, I thought you were going to say that! The bounded context is still something I don't grok in code and I think that's something I need to resolve soon. When discussing concepts at a high level I find it easy to see the bounded context but just don't know how to code it. Is it the case that DRY competes with bounded context? Or is that being over DRY (arid?) is an anti-pattern and bounded contexts is a technique to fix it... I guess the first step is to acknowledge that I have a problem :-) Scott http://ayende.com/4077/feature-by-feature#comment17http://ayende.com/4077/feature-by-feature#comment17Thu, 23 Jul 2009 18:49:56 GMTTomasz, It is situation dependent, so I can't really answer. But something like Searching on Documents or on Orders would likely have some minimal common infrastructure and exist in two places http://ayende.com/4077/feature-by-feature#comment16http://ayende.com/4077/feature-by-feature#comment16Thu, 23 Jul 2009 18:23:03 GMTVaid, Vadi, The concept of a NewOrder is usually a pretty big one in most system.s Usually we have things like: NewOrder Orders - list / view / cancel ChangeOrder Sometimes it CancelOrder is complex enough to deserve its own feature. In that case, it will probably Orders\NewOrder, etc. http://ayende.com/4077/feature-by-feature#comment15http://ayende.com/4077/feature-by-feature#comment15Thu, 23 Jul 2009 18:17:51 GMTScott, That is where you can apply the notions of bounded contexts. It is also important to understand that things like data storage are _different_ between features. How I store the tracks data for search may very well be different than the way I store them for playlists. http://ayende.com/4077/feature-by-feature#comment14http://ayende.com/4077/feature-by-feature#comment14Thu, 23 Jul 2009 18:09:55 GMTI'm digging this, and would love to see more concrete examples like this. For example, how is the pub/sub implemented? (I'm sure it uses Rhino, but how exactly do the features consume it, etc) Just go ahead and release the code already =) On saying bye to layering, I agree. I've been keeping most of our solutions to three assemblies: [Company].[Project].Web (or Win, etc), [Company].[Project].Library and [Company].[Project].Tests. Only when I absolutely need to use part and only part of nnn.library elsewhere do I split it up. Publishing interfaces for 3rd party webservice consumers to use without also publishing implementation, for example. Anything else is just academic. http://ayende.com/4077/feature-by-feature#comment13http://ayende.com/4077/feature-by-feature#comment13Thu, 23 Jul 2009 16:42:37 GMTI like the concept but I find it hard to see how you could separate things so cleanly. Here's an issue that I'm dealing with: The website I'm working on involved a database full of bands who submit tracks (among other things) and manage them. Next, we have a media player that allows users to play theses tracks and also include them in personal playlists. Those are 2 distinct features to me, but share lots of stuff. I think this is a great topic and hope you have lots more to say about it! I find project setup, organization, configuration to be the hardest thing to manage as a developer. The code comes easy, where to put the code is what takes up a lot of my time. http://ayende.com/4077/feature-by-feature#comment12http://ayende.com/4077/feature-by-feature#comment12Thu, 23 Jul 2009 15:25:30 GMTI think, what you intend say is something simliar to Procedure Oriented Programming paradigm. Each function carries its own purpose, may not be generic in nature. I see the same inheritance happening in your approach. http://ayende.com/4077/feature-by-feature#comment11http://ayende.com/4077/feature-by-feature#comment11Thu, 23 Jul 2009 14:31:52 GMTIt's true that more and more people (me included) consider 'code reuse' as a bad thing (at domain level). Think more 'service use' (this is achieved through pub/sub in your case). http://ayende.com/4077/feature-by-feature#comment10http://ayende.com/4077/feature-by-feature#comment10Thu, 23 Jul 2009 14:26:46 GMTI like this idea ... but something is bugging when i see NewOrder folder in your project structure. Would you meant to have ExistingOrders, DeletedOrders, ShippedOrders, CancelledOrders etc., Is that viable to go by this approach? may be if Ordering System is what you intend to develop, then "NewOrder" is a feature or core functionality?. I also think features are implemented above on a basic functionality of the business requirements. I would develop a "OrderByPhone" feature for a "Grocery Ordering System" ... Or, may be we are confused with the term "Feature" ....we need to elaborate more ... http://ayende.com/4077/feature-by-feature#comment9http://ayende.com/4077/feature-by-feature#comment9Thu, 23 Jul 2009 14:26:17 GMTBut what do to when two (or more) features have some common parts ? For example, two features have many same elements (methods, etc) in SearchCriteria (according to solution example screenshot). What to do ? Leave it and have duplicated code ? Move common parts to infrastructure ? Or create 'common features' place (directory in solution or separate project, .... ) and reference it in features ? http://ayende.com/4077/feature-by-feature#comment8http://ayende.com/4077/feature-by-feature#comment8Thu, 23 Jul 2009 13:45:08 GMTThis is very interesting, and will give me much to think about in the future. http://ayende.com/4077/feature-by-feature#comment7http://ayende.com/4077/feature-by-feature#comment7Thu, 23 Jul 2009 13:03:11 GMTJoe, Please drop it in the queue [nhprof.uservoice.com/.../263744-new-posts-ideas](http://nhprof.uservoice.com/pages/17880-general/suggestions/263744-new-posts-ideas)http://ayende.com/4077/feature-by-feature#comment6http://ayende.com/4077/feature-by-feature#comment6Thu, 23 Jul 2009 12:49:18 GMTLIke Josh Rivers said in the comments of the previous post, I think we get the big picture but the level of abstraction of your posts is maybe too high. Or I'm too ignorant. But I think you will spread your message more easily with a little more of code/sample. http://ayende.com/4077/feature-by-feature#comment5http://ayende.com/4077/feature-by-feature#comment5Thu, 23 Jul 2009 12:42:01 GMTAny plans on writing about the infrastucture that allows this type of architecture? Myself and I am sure others would love to hear your take on composite apps. http://ayende.com/4077/feature-by-feature#comment4http://ayende.com/4077/feature-by-feature#comment4Thu, 23 Jul 2009 12:36:16 GMTI completely agree. I took that same direction on a project some years ago (without really knowing DDD or all the cool new stuff). Self-contained feature in Self-containg modules. There is really no layering anymore ... I view it as a set of independent but cooperating 'cylinders' (going all the way top-down from the UI to the storage). Just add a height dimension to your bounded context to make it become 3D and you get the idea ... Also check this : [www.goeleven.com/blog/EntryDetail.aspx?entry=133](http://www.goeleven.com/blog/EntryDetail.aspx?entry=133) http://ayende.com/4077/feature-by-feature#comment3http://ayende.com/4077/feature-by-feature#comment3Thu, 23 Jul 2009 12:28:43 GMTHi Ayende, this makes a lot of sense. It would work really nicely with BDD, with each feature having its behaviour all in one place rather than spread across several layers. http://ayende.com/4077/feature-by-feature#comment2http://ayende.com/4077/feature-by-feature#comment2Thu, 23 Jul 2009 11:59:23 GMTWhat you call a 'feature' really looks like a bounded context.. http://ayende.com/4077/feature-by-feature#comment1http://ayende.com/4077/feature-by-feature#comment1Thu, 23 Jul 2009 11:13:15 GMT