|
||||||
 We now have a linked in group, join the group if you are a regular reader and want to see who else reads this blog.
 |
Command-Query Responsibility Segregation (CQRS) is slowly but steadily gaining ground as an architecture that helps developers to develop scalable, extensible and maintainable applications. Events play a major role in this architecture, and the way you design these events greatly influence the extensibility of your application. In this post, I describe some CQRS event [...] Command Query Responsibility Segregation (CQRS) is an architectural style that makes a clear distinction between commands, which tell an application to do something, and queries, which are requests for information from an application. This distinction comes from the fact that the requirements (and thus also the model) for the execution and validation of commands are significantly different than those for queries. Events play an important role in the synchronization of application state resulting from executed command. Applying a CQRS style architecture involves the development of quite a lot of “plumbing” code: event dispatching, asynchronous event processing, transactions, etc. cqrs4j, an Apache 2 licensed open source framework, takes care of all the plumbing for you. Read on to find out how… Continue reading CQRS made easy with cqrs4j Implementing an equals method in Java can be quite complicated. Fortunately there are numerous document around the web with useful tips, hints and frameworks to assist you in this process. However, an implementation of the equals method that is technically correct doesn’t have to make any sense functionally. In Domain Driven Design, your domain model implementation is the beating heart of your application. Everything has to make perfect (functional) sense in there. Having good equals methods is of vital importance there. In this article, I will elaborate on some common pitfalls you can encounter when implementing the equals method, as well as some sensible guidelines. Continue reading Domain Driven Design and the equals method
Continue reading Designing the Repository interface As many other developers, I’ve been used to the fat service layer and the anemic domain model of the transaction script pattern. In that programming model, immutability is pretty much as rare as a Dodo. However, I have been investigating the rich domain model pattern lately (as you can read in my previous post) and more importantly, a good migration path for “transaction script” developers to get acquainted with the rich Domain Model, a design pattern that has been heavily underrated (and misunderstood) by many. In this post, I will explain some of the advantages that immutable domain objects bring us, while showing that some of the seemingly problematic side effects aren’t really that problematic. Continue reading The power of immutability in a Rich Domain Model
A commonly seen strategy to inject these dependencies is to call a static method from the constructor. This static method will inject the newly instantiated instance with its dependencies using a reference to Spring’s application context. Although this method seems effective, it is purely limited to dependency injection. Spring offers a lot more, such as transaction support and security. Spring’s load time weaving capabilty offers a more complete way to inject your unmanaged instances, making them no different than any spring managed instance. Continue reading Injecting Domain objects with Spring
Recently, SpringSource released the first version of their DM server. The SpringSource DM Server provides the ability to build enterprise web applications. In the basis, S2DM is a fine mixture of Equinox and Tomcat. Building OSGi-based web applications was already possible, but it is tedious and error prone work. The typical hello-world example was easy to get going, but as soon as Hibernate or any other framework that helps in larger applications show up, so do your good old class loading problems. For classes to be visible in OSGi, a bundle must declare an Import-Package entry in the Manifest file. Chances are small that Hibernate (even if it were packaged as an OSGi bundle) has these entries for your persistent classes. This is where S2DM server comes in. It allows the more-than-hello-world web applications to be deployed in an environment where you can benefit from the best of OSGi, without the class loading misery. To do this, they have included some extra Manifest entries that are translated to OSGi-compliant directives at load time. Comparable to the WAR, or better, EAR file, S2DM server supports the PAR file. A PAR file is much like a Jar, with some special headers in the Manifest file, containing all your bundle jars. Some of these jars may contain web bundles, while other typically contain domain classes or the service layer implementation. Contrary to EAR files, a PAR should only contain your own code. It is best practice to deploy frameworks and third party libraries separately. I’ll explain why later on. With enterprise applications come enterprise development processes, using continuous integration, build servers and maven. In this post, I’ll lay out what you need to get maven to build S2DM server compliant bundles, and better, PAR files. Continue reading Building Spring DM server compliant OSGi bundles with Maven
Software Architects play an important role in setting up an architecture that can cope with these high demands. At the JAOO, Michael Nygard‘ had a talk, “Failure comes in Flavors“, that gave very good insight in the risks and opportunities of today’s application. The talk was was divided into two sessions. The first session covered the bad news: the stability threats. He discussed several situations that pose a threat to the long and happy life of an application. The second session was a happier one. It covered the patterns that should be applied to the application architecture to prevent these threats. In this post, I will elaborate on some of the stability threats and pick one specific pattern to resolve them: the circuit breaker. Continue reading Bring some stability to your architecture |
|||||
|
Copyright © 2012 Gridshore - All Rights Reserved |
||||||
Using Spring, it is easy to inject any instance with its dependencies, as long as the instance is managed by the Spring container. This typically means that the to-be injected beans are configured in the XML configuration. However, sometimes, it is impossible or ugly design to have objects managed by the Spring container. For example, when using a Rich 
Applications have to run in high-consequence environments. They have to serve hundreds of thousands of users 24 / 7. Our clients spend millions in hard- and software and highly depend on the revenue generated by these applications. Unnecessary outage of these application is fatal.