Enterprise development is changing, and we need to change too

 In this post, I'd like to address some changes I've been seeing in the way enterprise applications are developed, and how this affects how we, as enterprise developers, need to change along with that trend. We need to learn new skills, change the way we look at our every day job and the requirements it has. We're accustomed to working in an Agile way in our day to day lives, so look at this post as a retrospective of our own work, and the implications it has.  Observing the history of the enterprise development world But let's start out with why I'm interested in these changes in the first place. My job at GROUP9, the company I work for, is twofold. Partly I'm a consultant working for our various clients, often in the role of architect, helping our clients in creating software solutions and in general becoming better at delivering these solutions. However, my other, internal, responsibility is that of competence manager. Basically that means ensuring our consul

Code review vs. Pair programming

 Introduction The other day, I had a discussion with a colleague of mine, about his new role as lead developer in a team. We were talking about the fact that when you are the lead developer of a team, you often bring a certain set of opinions with you on how to do software development within the team you lead. As this was his first assignment as lead developer, we had a discussion on what these opinions were; what will he bring to the team and how will he shape the way they develop their systems? Soon, we came to the subject on the act of reviewing code, and more specifically, using something like BitBucket code reviewing options to execute a formal review, offline, to approve a pull request from another team member. My colleague indicated he really disliked these formal code reviews, and likes pair programming way better. This sounds quite like an opinion on how to do software development in your team 😅. However, this got me thinking, as we see in quite a few places at our customers&

Validations across micro-services

On my day-job as a consultant for GROUP9  we had an interesting discussion on how to handle validations across micro-services. Let's look at this in the context of a fictionalized example. Example: amazon selling for other companies The case we were discussing was the typical case of referential integrity between two objects. Imagine this: we're Amazon, and being a large e-commerce platform, we want to enable other sellers to use our platform to sell their products, while we handle all the logistics (and of course get a percentage on every sale 😁). To achieve this, we come to an agreement with a seller after some negotiations, e.g. agreeing on the commission percentage we receive on every sale. During these negations, we can add some of the products of that seller to our platform, show them the pricing, additional information etc, so the seller can have an idea what his products would look like when promoted on our platform. Being Amazon, we of course have a micro-services lan

How Lombok can throw you off guard - Java Compiler fun

Working on a project on a customer of mine, I bumped into some very weird Lombok behavior which really caught me off guard. As it was caused by a not-so-easy to debug issue, I'd like to share with you all what happened and why. Enter WTF After making some changes to the Maven POM structure, and doing a compile of the code, maven reported the following errors: [ERROR][20,43] cannot find symbol [ERROR]    symbol: class __ [ERROR][17,32] cannot find symbol [ERROR]    symbol: class __ [ERROR][21,33] cannot find symbol [ERROR]    symbol: class __ [ERROR][78l,13] cannot find symbol [ERROR]    symbol: method getValue() [ERROR]    location: .... Of course, I knew  we're using Lombok to generate Getter, setters etc for our classes, so for some reason Lombok was not being run, causing the @__ annotation still being present, and the getValue() method not being generated during compilation. What was even mor

Bridging the world of Event Storming and BPMN

In a recent post , Bernd Ruecker made a nice post on a pattern to transform events to commands in MicroServices and DDD. The post discusses the differences between Choreography and Orchestration as two major styles in which various micro-services can be connected and the pros and cons of these styles. Creating business process based systems using DDD is something I've been working on quite a bit. In this post, I would like to take this one step further and also show how the worlds of BPMN and DDD have a very nice fit, even b eyond than just this pattern. To do this, I'm going to make a connec tion between BP MN and a prominent style of analysis in the DDD world - Event Storming by Alberto Brandolini . Also, I'd like to dive into how the strategic design parts of DDD can help us in guiding us where we would like to apply these patterns. The latter will be subject of a later post. Event Storming First things first, lets look at Event Storming and how it is used in DD

From Multi-Threaded applications to Multi-Time applications

At the DDD Europe conference.. Recently, I visited the DDD Europe  conference, where Vaughn Vernon held a talk on using Akka an the Actor model to implement applications, based on the principles of Domain Driven Design. This talk, combined with some recent issues I've been facing at my customers site, inspired me to think about the design issues you face when developing multi-time applications. But let's start with what Vernon was talking about at his talk. Vernons talk His main premise: the Actor model is a more simplified model for application development, while at the same time providing a thread-safe environment to fully make use of the ever increasing number of cores processors have. While CPUs don't get any faster, in terms of pure clock speed, they do get more cores, and the we need to adapt our software to make use of these multiple cores. Traditional programming models don't scale nicely because of IO waits causing the software to block and the CPU being

In-Reply-To: Danny's Object Oriented Programming Access Modifiers

Abstract Danny van Heumen , my co-worker at GROUP9 , has written a series of blog on his thoughts about Object Oriented Programming. In this blog I share my views on his ramblings ;-). The TL;DR version: I argue that his notion on access-modifiers and seemingly strange design choices are not caused by the design choices themselves but by not viewing OO design at the package level and the often seen way of defining packages in Enterprise applications where packages don't expose a clear, minimal API towards other packages. On access-modifiers At GROUP9, we've been discussing a  bit about object oriented programming and designs and how to do it "right". In his post on access modifiers  as part of a larger series of posts on OO, Danny argues a lacking access modifier and argues that the protected access modifier (the context is Java here) allows to wide access. I'm missing the actual explanation of which access modifier he's missing, however I'm presu