http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660I'd add that this is probably a textbook example of where Role Objects could be useful (http://martinfowler.com/apsupp/roles.pdf)http://ayende.com/153704/composite-entities#comment27http://ayende.com/153704/composite-entities#comment27Thu, 05 Apr 2012 04:12:33 GMTMatthew, This is just basically a convention for the naming of ids, nothing else. There is nothing special about it otherwise.http://ayende.com/153704/composite-entities#comment26http://ayende.com/153704/composite-entities#comment26Sat, 24 Mar 2012 11:48:32 GMTIs there more information on this, perhaps showing basic crud on the various entities and how they're stored in the db?http://ayende.com/153704/composite-entities#comment25http://ayende.com/153704/composite-entities#comment25Sat, 24 Mar 2012 00:04:05 GMTI am still a bit confused. I get how the connection is made in the database but how would the access to customer name look in code using an OR/M How would you use helpDestCustomer.Name within the domain object without going through some sort of repository?http://ayende.com/153704/composite-entities#comment24http://ayende.com/153704/composite-entities#comment24Thu, 22 Mar 2012 11:16:23 GMTThis is a great example and is the exact issue addressed by DDD bounded contexts (BCs). There is one notion of a customer and the identity value is shared, however the model is different in each BC. The problem with BCs in DDD is that they aren't introduced until midway through the blue book and aren't sufficiently emphasized as a top level module mechanism. Furthermore, the pattern is relevant outside of DDD and applies in more data oriented applications just as well.http://ayende.com/153704/composite-entities#comment23http://ayende.com/153704/composite-entities#comment23Mon, 19 Mar 2012 18:41:52 GMTFair point... often billing address will be different. If it makes sense in the domain, then I can see composite entities will help. Having thought about it some more the problems you have to deal with with here (data duplication/replication) are probably much less complex than the alternative. Again some good stuff for me to consider thankshttp://ayende.com/153704/composite-entities#comment22http://ayende.com/153704/composite-entities#comment22Sat, 17 Mar 2012 23:52:01 GMTThor, Look at the ids that I have there: customers/1/billing customer/1/help-desk They share the ROOT id, but they have extensions based on their purposehttp://ayende.com/153704/composite-entities#comment21http://ayende.com/153704/composite-entities#comment21Sat, 17 Mar 2012 08:59:24 GMTRowen, In our company, we have the main offices in one location, and all of the accounting is handled in a separate location. I actually DO need billing address to be different than the helpdesk address. And that is pretty common for many organizationshttp://ayende.com/153704/composite-entities#comment20http://ayende.com/153704/composite-entities#comment20Sat, 17 Mar 2012 08:57:39 GMTBpd, Sure, let us take this for example. What _is_ a company name? It is pretty common to have a name that is used for things like marketing, and a separate name for legal reasons. It may simple be the difference between "Microsoft" and "Microsoft, INC" and it can be totally different names. Changing the legal name doesn't imply changing the public name, and vice versa.http://ayende.com/153704/composite-entities#comment19http://ayende.com/153704/composite-entities#comment19Sat, 17 Mar 2012 08:55:52 GMT@Matt, Look at the bottom of the article, it was published on 3/16, but it was posted on 1/14. It is not uncommon for some people to have early access to posts. This was probably the case there.http://ayende.com/153704/composite-entities#comment18http://ayende.com/153704/composite-entities#comment18Sat, 17 Mar 2012 03:18:06 GMTHow did Daniel's comment come through with a date of 01/17/2012 when this was just posted today on 3/16/2012? ;)http://ayende.com/153704/composite-entities#comment17http://ayende.com/153704/composite-entities#comment17Sat, 17 Mar 2012 01:31:43 GMTThis doesn't sound like a data modeling problem as much as a figuring out your business domain problem. I can see plenty of situations where either a customer is your only point of contact, or helpdesk personnel does need to change billing information.http://ayende.com/153704/composite-entities#comment16http://ayende.com/153704/composite-entities#comment16Fri, 16 Mar 2012 23:58:41 GMT@Steve We don't integrate the products, but spend time integrating the data into a warehouse, which then serves as a single source of truth. Applications that own data can write their data to the warehouse, but other applications can only read it. This is actually a very hard problem to solve for most big organizations that accumulate people, data and assets in a highly fragmented manner. That's why stuff like Master Data Management even exists: http://msdn.microsoft.com/en-us/library/bb190163.aspx#mdm04_topic3http://ayende.com/153704/composite-entities#comment15http://ayende.com/153704/composite-entities#comment15Fri, 16 Mar 2012 20:22:26 GMTHow would you correlate between the different facets of a customer? We have a similar approach, and we are using RavenDB. The different facets cannot share Id, so AFAICT we need some kind of object/document to correlate between the facets. Or can this be done using a composite id somehow?http://ayende.com/153704/composite-entities#comment14http://ayende.com/153704/composite-entities#comment14Fri, 16 Mar 2012 19:46:44 GMT+1 Jay - YES, CQRS! I think as long as you have one model serving two masters (reads, writes) eventually there will be conflicts, trade-offs, and possibly mud.http://ayende.com/153704/composite-entities#comment13http://ayende.com/153704/composite-entities#comment13Fri, 16 Mar 2012 18:18:09 GMTSeems like standard composition over inheritence to me. You can still have a "Generic" customer with the domain associated data as a seperate entity off your customer. http://ayende.com/153704/composite-entities#comment12http://ayende.com/153704/composite-entities#comment12Fri, 16 Mar 2012 17:16:15 GMTIsn't this a perfect scenario for CQRS? Billing and Helpdesk require different read models. Shared attributes like Customer Name will be propagated to all read models, but an attribute like OutstandingSupportCalls would only be needed for the Helpdesk read model. http://ayende.com/153704/composite-entities#comment11http://ayende.com/153704/composite-entities#comment11Fri, 16 Mar 2012 15:51:28 GMTRowen - In most businesses, to solve the problem of working independently they work entirely independently. So you have help desk maintaining an address, and billing maintaining an address. Oren is suggesting here a way of managing that common data in a way that doesn't interfere greatly with development team independence. That being said, many businesses buy a lot of software like billing and helpdesk off the shelf and integrating two third party products together is damn near impossible.http://ayende.com/153704/composite-entities#comment10http://ayende.com/153704/composite-entities#comment10Fri, 16 Mar 2012 15:33:21 GMTI don't think Oren is saying the billing business unit won't change the name, it's just that any changes to the name will go through a customer service. So there's only one way of making that change, in order to manage change propagation. If you have independent systems, most likely a pub/sub notifying of such a change. A one way change propagation is relatively easy, it's harder to do a two way. http://ayende.com/153704/composite-entities#comment9http://ayende.com/153704/composite-entities#comment9Fri, 16 Mar 2012 15:29:22 GMTFor certain scenarios this sounds great... but I get really annoyed when I update my address with helpdesk and the next bill I get still has the old address... I want them to share that information... and of course with this architecture that is possible but much less likely (unless all devs have a good understanding of the business model which is not always the case). In my real life experience (not as a developer but from a customer/consumer point of view), multiple versions of the truth involve multiple phonecalls, multiple forms... and are a real pain when not done right. I think one version of the truth is more painful for developer/business but better for the consumer... unless the multiple versions are managed very well (so that the 'real' truth is always reflected accurately)... in which case there is development pain regardless. Unless I am missing something (which is entirely possible ;) I don't see an easy solution here... maybe I am looking at this from too much of an rdbms perspective?http://ayende.com/153704/composite-entities#comment8http://ayende.com/153704/composite-entities#comment8Fri, 16 Mar 2012 15:09:18 GMTThere's also the possibility of implementing entities via mixins (as provided by re-mix). An entity can include mixins in order to integrate functionality defined by generic modules, and use-case specific modules can define mixins that extend the entity with use-case specific code. Here's a longer explanation: https://www.re-motion.org/blogs/mix/2012/03/16/re-mix-the-mixin-based-composition-pattern/ .http://ayende.com/153704/composite-entities#comment7http://ayende.com/153704/composite-entities#comment7Fri, 16 Mar 2012 14:12:56 GMTWhat we have done in the past is abstract the data away behind a service. This service could provide for the root data. It could also provide for data by business function too, albeit owners of the root data likely would not support this as they are unfamiliar with it. Root data could be merged with business specific customer data in the specific business application, and caching strategies could be put in place as the system scales out. Likely the root data changing (like Name) doesn't happen on a regular basis and isn't of utter importance in the business application anyway.http://ayende.com/153704/composite-entities#comment6http://ayende.com/153704/composite-entities#comment6Fri, 16 Mar 2012 13:49:12 GMT> I can’t see any reason why you would want to [update the root customer details] Because companies change their name. Mine did - twice in as many years. > billing shouldn’t update the customer name If not billing, then who?http://ayende.com/153704/composite-entities#comment5http://ayende.com/153704/composite-entities#comment5Fri, 16 Mar 2012 13:16:02 GMTThey don’t need to talk to anyone, **because no one else is touching their data**. (emphasis added) That's a very important assumption, which unfortunately doesn't hold true in our environment.http://ayende.com/153704/composite-entities#comment4http://ayende.com/153704/composite-entities#comment4Fri, 16 Mar 2012 12:32:51 GMT@Wayne M, there shouldn't be any duplicate data if the tables mimicked the class design above. dbo.HelpDeskCustomers wouldn't have a Name, that would live on dbo.Customers. Of course if they were in different databases or you wanted to avoid the join you could denormalise it by putting Name on dbo.HelpDeskCustomers and make a trade off between the time it takes to list help desk customers and the relatively few times that you change a customers name. http://ayende.com/153704/composite-entities#comment3http://ayende.com/153704/composite-entities#comment3Fri, 16 Mar 2012 12:25:18 GMTI'm a tiny bit confused here, is the idea that you would have separate tables in the database for each of thee customer types? So you would have dbo.Customers, dbo.HelpDeskCustomers, etc? Or did I miss something critical, because that sounds like an awful situation with lots of duplicate data.http://ayende.com/153704/composite-entities#comment2http://ayende.com/153704/composite-entities#comment2Fri, 16 Mar 2012 12:08:50 GMTThese are interesting thoughts, Oren. I agree with most of them, except that I would denormalize the shared information (the customers name and customers no) into every specialized customer. That way, it is _much_ to read the data, because in always every case I will need the customers name in conjunction with all other related data. That means, I would always have to query two tables/documents to get all the information that I need to populate a list, a details page or whatever. Actually I'm already doing things that way, but we don't allow different parts of the system to update the name and customer on their own. These are informations that change so rarely, that it is ok for us to have a DBA run a script for updating them. However, if this was something more common, we would probably have a webservice on the 'master' to do that.http://ayende.com/153704/composite-entities#comment1http://ayende.com/153704/composite-entities#comment1Tue, 17 Jan 2012 23:32:28 GMT