Hello! Thinking inside a bigger box is using DISQUS, a powerful comment system, to manage its comments. Learn more.
Community Page
- www.brodwall.com/johannes/blog/ Jump to website »
-
Subscribe -
Community
-
Top Commenters
-
Popular Threads
-
Recent Comments
- The evolution of SOA Introduce the concepts of services and SOA Design principles of SOA ... The benefits of employing SOA Review of common business goals ... Related articles. Web Application...
- Great article and I agree with you that ............ Thanks for the tips!
- Great read, good work old chap :)
- Hi...Your post really got me thinking man..... an intelligent piece ,I must say.
- Was a good read. thank great post, I think this article is useful. I'll be back for more. Thanks for sharing the information . .. :)
Jump to original thread »
Status: This article is currently pretty dry. I’d like feedback on how to make it more eloquent.
In my previous blog post, I promised to write more about using databases as the main integration strategy. In the current post, I plan to cover maybe the most important question: %2 ... Continue reading »
In my previous blog post, I promised to write more about using databases as the main integration strategy. In the current post, I plan to cover maybe the most important question: %2 ... Continue reading »
2 years ago
first I would like to say that I really enjoy reading your blog, exiting and insightful ideas that seems to be based on many many years of experience. really worth listen to!
but I really cant wait for the "how"-part of this serie, so here are some questions:
-how is it possible to trigger a business function in another application using your shared database strategy? I guess that all applications have access to all the data in the database, but what if an application A want another application B to do some calculations on a specific set of data. how do application A trigger this calculcation in app B? (I presume that you want to avoid the nightmare of stored procedures)
-how can you avoid that the applications get tight coupled? when the apps share and communicate trough a shared database then they have to know and use the inner data structures of the other applications. this will make them strongly coupled. if you change the structures of one application this might affect three others... isnt this like really entering the world of spaghetti?
-will it not be hard to change the technology that one of these applications are based upon? when the database layer are merged together and there are no explicit system borders in the database layers, how can you manage to replace the technology... isnt the system borders in a database just to vague and implicit? isnt it much better to move the system borders for instance up in a service layer?
my philosophy is that applications that solves different problems and that actually explicitly are separate applications should (if they have to communicate at all) know as little about each other as absolutely possible! and I dont see how you achieve this goal with the shared database strategy!
2 years ago
The issues you take up are important, and I will let the feedback decide what I write about next. Specifically:
* I say: "The world is flat". You say "a large flat world is confusing". This is true. The world should not be flat, but from certain viewpoints, it should appear flat. I'll talk more about this later. This is how I want to address complexity and coupling.
* I had not originally thought about writing about triggering business functionality, but I'll incude our current work on this in a future post. (This was actually what triggered the whole Single Database Vision idea for me) And, like you, I am not a proponent of Stored procedures