tag:blogger.com,1999:blog-5763764290649132593.post4682390618605384005..comments2023-08-09T13:17:49.225+02:00Comments on CLOSED-LOOP: SOA vs. DRYAnonymoushttp://www.blogger.com/profile/00990537252799084615noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-5763764290649132593.post-58950192655015492362013-04-13T18:47:42.965+02:002013-04-13T18:47:42.965+02:00Just adding a quote from Dan North at GoTo Zurich:...Just adding a quote from Dan North at GoTo Zurich:<br /><b><br />"DRY ist the enemy of decoupling."<br /></b><br /><a href="https://twitter.com/xnka/status/322252783183093760" rel="nofollow"><br />https://twitter.com/xnka/status/322252783183093760<br /></a>Anonymoushttps://www.blogger.com/profile/00990537252799084615noreply@blogger.comtag:blogger.com,1999:blog-5763764290649132593.post-62242406851457653482013-03-01T17:46:59.135+01:002013-03-01T17:46:59.135+01:00@Daniel
Hijacking is always welcome. Especially if...@Daniel<br />Hijacking is always welcome. Especially if the comments are as valuable as yours :-) Anonymoushttps://www.blogger.com/profile/00990537252799084615noreply@blogger.comtag:blogger.com,1999:blog-5763764290649132593.post-44179150229861796672013-03-01T12:18:18.898+01:002013-03-01T12:18:18.898+01:00Yes indeed. As always every technology or architec...Yes indeed. As always every technology or architecture/style choice comes with its benefits but also disadvantages regarding maintainability, versioning etc. so there is no silver bullet.<br /><br />BUT I see advantage in an architectural style which forces you to think about those kinds of questions early in your process. Often people don't do it and run into a lot of troubles afterwards. Regardless of you use the monolithic or distributed approach the questions to be asked are often the same. The answer can be different.<br /><br />Applying true SOA style is hard for most teams. They don't want to leave their comfort zone of traditional RPC thinking. Also having multiple schemas/domain models in multiple databases scares people. Often I see also a huge force which draws people to more centralization. For example if you talk about a customer, developers usually see an entity type customer which ultimatively leads to centralized thinking. They fail to see that different business contexts have their own notion of a customer and their only common notion is a customer ID. So the data of a single customer resides in multiple schemas/databases with even possible redundancy. This freaks out most developers with strong database knowledge.<br /><br />Another area is applying good commands and events which are purely business focused and not technical... Maybe we should do a usergroup about this topic, because I dom't want to hijack your blogpost :)<br /><br />DanielDaniel Marbachnoreply@blogger.comtag:blogger.com,1999:blog-5763764290649132593.post-78932293610500588972013-02-28T23:49:03.824+01:002013-02-28T23:49:03.824+01:00@Daniel
I completely agree with your comment.
Th...@Daniel<br /><br />I completely agree with your comment.<br /><br />The point is, that in most projects I have been on this awareness was not there... at least not from the start.<br /><br />I also think that if you embrace this fact, SOA gets a lot less attractive for many projects. (i.e. when the same team is responsible for all the services).<br /><br />Of course you can develop shared infrastructure in a way that it can be deployed in different versions to different services. But it complicates your live a lot (technically compatibility, governance, maintenance ...). So you really should be sure that it is worth it ...Anonymoushttps://www.blogger.com/profile/00990537252799084615noreply@blogger.comtag:blogger.com,1999:blog-5763764290649132593.post-89531454001646663282013-02-28T21:13:03.276+01:002013-02-28T21:13:03.276+01:00Sorry last comment got published anonymous. It was...Sorry last comment got published anonymous. It was me :)Daniel Marbachnoreply@blogger.comtag:blogger.com,1999:blog-5763764290649132593.post-79885870541293494192013-02-28T21:11:30.982+01:002013-02-28T21:11:30.982+01:00Hy jonas
I would argue that if you apply true SOA ...Hy jonas<br />I would argue that if you apply true SOA style architecture as proposed by Udi Dahan, Bill Poole and many more in contrast to Thomas Erl SOA having a centralized domain model violates the four tenants of service oriented architecture. Because each individual service (by service I do not mean web service!) is the only owner of a certain business data other services can never have the same notion of the data so this leads to the conclusion that a shared domain model is per definition a design flaw.<br /><br />But certainly it has a valid point there. For example infrastructure is deployed to multiple services which then introduces artifial coupling. BUT infrastructure doesn't need to evolve at the same pace. For example part of your common infrastructure is creating word 2010 documents. This library is deployed to service A and B. when service B need the ability to produce 2013 docs but service A doesn't (let's say the department which collaborates mainly with service A will not be upgraded because of some other legacy word plugin), service A could still reference V1.0 of the infrastructure lib and doesn't need to be redeployed. The most important point here is that you have to make explicit decisions Anonymousnoreply@blogger.com