-
Subscribe -
Community
-
Top Commenters
-
Popular Threads
-
Recent Comments
- Thanks for your comment. I've encountered people who talk about non-distributed SOA. I think that is an idea that is totally boring, as it says nothing that hasn't been said for twenty...
- In the text you, like most I think, define services to be distributed. I do not understand why everybody i
- Hi, Eve Thanks for the offer. Let me know if there's any way I can make it easier. Do you think I should consolidate all the articles into one, for example?
- I'd be more than happy to read drafts, run through example code, and whatnot. I've done a little bit of Rails work, but I'm enough of a noob that I'll be able to give good feedback...
- I've never had much luck with the precreated keys. But then again, I use the convention of a null-key to indicate unsaved objects, so I'd run into other problems. FWIW, it sounds like your...
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