Hi Patrki, just needed time to do mental work. I was thinking about your proposal. Than I will have free tied entities. For example in ORG module I have Employee and in CMDB module will have CMDBEmployee with link to Employee like:
Entity CMDBEmployee { Long originEmployee; ... } I was dreaming more about some automatic sharing attributes, automatic spliting and merging entities, ... . Is here some generic pattern, technology which we can support in Sculptor regarding this? Some generic concept in Spring, SOA (ServiceMix 4, Eclipse Swordfish, ...) which can be implemented in Sculptor? I'm just trying to find something common what should be useful for others. I know how to do it manually in SOA or using some other technologies. But maybe here is some standardization going on. Something like: BusinessEntity CentralEmployee { String firstName searchable readonly -> OrgEmployee.name, HrEmployee.firstName String secondName searchable readonly -> OrgEmployee.lastName, HrEmployee.secondName String title readonly -> OrgEmployee.title String eyeColor Date birthdate searchable readonly -> HrEmplyee.birthdate HrEmployee hrDetail -> HrEmployee.* except firstName, secondName CmdbEmployee cmdbDetail -> CmdbEmployee.* } Business entity will remember all set operation and set dirty flag for specific entities which need to be saved and allow to get specific entities like 'createHrEmployee' which will return HrEmployee object. Similar to this service: BusinessService EmployeeService { save -> OrgEmployeeService failfast recover, HrEmployeeService.save ignoreerror, CmdbEmloyeeService.save ignoreerror } I have in ming many concept around this like transaction control, messaging, search database, orchestration, ... . You are wise man, you read even more than I about concepts. Do you have something in mind regarding this? Am I totally foolish if I want achieve this? Pavel On Fri, Apr 9, 2010 at 7:28 AM, Patrik Nordwall <patrik.nordw...@gmail.com> wrote: > > My intuitive recommendation is that you should use seperate representations > in the different systems. More flexible and less dependencies between them. > > I think it is bad to share db between systems. Each should own it's data, > but replication (via message bus) might be needed. Each system can store > it's own representation. Only one should be master (responsible for updating > data). > > In ddd terms this is about different bounded contexts and anti-corruption > layer. This is absolutely not the only ddd strategic design pattern. Read > more in the ddd book or in this article > http://www.infoq.com/articles/ddd-contextmapping > > /Patrik > > PaloT wrote: >> >> Hi, >> maybe this is not right forum but I know that many clever brains watch it. >> >> I have following problem: >> We have organization structure with Employee entity, pretty simple. >> Now we are going to implement ConfigurationDatabase system (CMDB). I >> have to add some attributes to Employee (machines which he >> administrate, ...). Than we are implementing sales system. I have to >> again add some attributes to Person like teritory, distributionPhase, >> ... . And than problem come when I want deploy and combine different >> systems for customers (with sales system, without CMDB, ...). How to >> solve this? >> >> a) Create independent systems with CmdbEmployee, SalesEmployee and >> create higher level on bus (SOA) which will care about merging and >> spliting all entities together >> b) We will provide some kind of mixins in Sculptor DSL which will >> allow merging entities (CmdbEmployee mixin Employee) >> c) AspectJ ITD >> e) Any other better idea? >> >> Thanks for ANY hint you can provide >> >> Pavel >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Fornax-developer mailing list >> Fornax-developer@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/fornax-developer >> >> > > -- > View this message in context: > http://old.nabble.com/Higher-abstraction-level-tp28177781s17564p28188159.html > Sent from the Fornax-Platform mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Fornax-developer mailing list > Fornax-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fornax-developer > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Fornax-developer mailing list Fornax-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fornax-developer