Architecture
In the last several years I’ve seen several projects suffering from performance problems caused by one bad decision: inadequate choice of storage. As Greg Young noted developers often stick to RDBMS without even considering the alternatives. I’m not going to discuss SQL vs. NoSQL, but rather share some ideas on what might affect the decision. Data life time In one of the projects I’ve been involved in, there was an incoming stream of real time geo location data from hundred of thousands of users. While the whole system generally worked well the performance of geo-location data storage...
posted @ Sunday, March 28, 2010 2:04 PM |
I’m starting a series of posts “Don’t” about patterns and design decisions I consider bad. Some of them are learned the hard way, through bad judgment and painful experience. While at certain circumstances some of the patterns described can be useful, they are mostly don’t work well in a general case. Open session in view “Open session in view” (OSV) is a web-oriented (anti)pattern that opens ORM session at the beginning of the request and close it when view rendering is done (session is maintained by a servlet filter (Java) or http module (ASP.NET)). Why one might...
posted @ Sunday, November 15, 2009 3:20 AM |
The alternative way to going Request/Response communication style is one-way asynchronous messaging. While at first this seems much harder, it is much more connected to the way you think of the processes than to technical issues. Once you get used to modeling processes in asynchronous way you will discover that much of the processes happening in the enterprise or around you are naturally asynchronous. Example Let’s analyze something that is easy to touch – project development process itself (well simplified). Let’s model the process of releasing a build for testing in both ways (sync and async). ...
posted @ Tuesday, November 03, 2009 10:23 PM |
One of the questions that frequently arise on the Domain Driven Design mail list is how to build the query side of CQS? The most popular approaches are as follows:
Go the 2-tier way and query the store directly from the client
Implement some sort of thin DTO layer on top of the query store
If the Query side in question is not some sort of BI support store I personally prefer the second approach because of security. Putting security checks on the client is something I can’t...
posted @ Monday, October 26, 2009 9:31 PM |
Today almost every project involves some sort of distribution: interaction with some legacy system, some sort of authentication service, etc. Teams tend to solve the distribution problem by applying easily understandable RPC-style technologies. Not that RPC-style communication broken by definition, but it tends to make some very strong assumptions on the channel and the availability of the remote component.
The implicit assumptions
From developer perspective RPC looks very attractively: the remote object looks just like it it was on the same machine - the undelying technology takes the responsibility for serializing requests and deserializing method returns back. Just like calling a local...
posted @ Sunday, July 12, 2009 7:47 PM |