slash dev slash null

stuff about puters

“Agile” Isn’t A Helpful Description; Lets Call It “Rapid Feedback”

When the Agile Manifesto came out in 2001 I was working at a DotCom in the City Of London and missed the memo. In a small startup, with only a few developers, working directly for clients, there wasn’t much scope for some big process waterfall. Oh the good o’ days.  Me, the code, the client and the ‘puters in that order. Honour and glory were assured… Read the rest of this entry »

Failures In Distributed Databases

The “Morning Paper” blog has some fascinating insights into critical production failures in distributed data-intensive databases such as Cassandra and HBase. This reveals that simple testing can prevent most critical failures. In this blog post we take a quick look to see what an embeddable Paxos algorithm project such as Trex can learn from this study.  Read the rest of this entry »

The FPaxos “Even Nodes” Optimisation 

Up until 2016 it was well understood that the optimal size for typical Paxos clusters is three or five nodes. With typical replication workloads it has been established that four or six nodes clusters are no better, and in fact worse, than having one less node. The FPaxos “Flexible Paxos” paper changes the rules of the consensus game with the “even nodes” optimisation.  Read the rest of this entry »

Trex now supports Flexible Paxos (FPaxos) Strategies

2016 has turned out to be a great year for Paxos with the discovery of a more flexible Paxos known as FPaxos. Only a simple change was required to the TRex paxos JVM library to support this new discovery. You can now supply a pluggable QuorumStraregy which can do things like “grid consensus”. The code on the master branch now has a default strategy which does the  “even nodes” optimisation. Enjoy!

Agile and domain driven design (part 3): Microservices

In the last post we imaged we are a programmer on an agile digital service team who had gotten as far as writing some DDD code. It is a rich OO domain model that knows how to obey the business rules (aka enforce the invariants of the contract aggregate). The next question is where should this code run? What provides the surrounding workflow? Which screens, running where, drive this “thing”? Talking it through with the other developers in the team you decided to build and deploy a contracts microserviceRead the rest of this entry »

Agile and domain driven design (part 2): Event Storming

The last post set the scene for how an agile digital services team gets to the point where it is ready to cut some DDD code. Imagine that you just joined the team as a programmer as the programme is ramping up its private beta build out. To align ourselves to the demo code of the last blog series you are need to build out some stories about how customers and your internal users create and agree a contract to deliver products. You are an agile analyst programmer who wants to build a ubiquitous language with the users of the system. So you attend an event storming workshop with the users. Read the rest of this entry »

Agile and domain driven design (part 1): Digital Services

In the last mini-series of posts I sketched out how to use DDD to build an explicit rich domain library that models the business domain and enforces the invariants within a narrow scope of an aggregate of entities. Catching up with my friend we got into a discussion about how we get to the point were are ready to implement things. How big can the model be? How do we scale to many two pizza teams? How do user needs, business processes, and screens relate to the domain focused OO design? We ended up talking about microservices. So in this series of post I am going to sketch how a large scale agile digital transformation programme gets to the point of cutting DDD code. I will then get into how a large project comes to be a platform with a micro-services architectureRead the rest of this entry »

Domain Driven Design: Entities, Value Objects, Aggregates and Roots with JPA (Part 5)

This is the last article in the series which discusses a sample app that does DDD using JPA. I would hesitate to recommend using JPA for DDD unless you are very familiar with JPA. Why? Some of the issues you can hit using JPA are written up on the Scabl blog on Advanced Enterprise DDD. In my own code and this blog I explain how to dodge some of the bullets but you need to be quite aware of the pitfalls of JPA to dodge them all. So why did I write the code? Read the rest of this entry »

Domain Driven Design: Entities, Value Objects, Aggregates and Roots with JPA (Part 4)

Don’t abuse the `public` keyword in Java. The source code has very few public classes or methods. This is unusual for Java projects. Typically Java projects have package layouts that model the solution; “this package has all the entities, that package has all database related code, that package is all the services code”. That approach forces you to make almost everything public. In the long term on a big project brittle connections are made across business responsibility boundaries. There is no way the compiler can enforce boundaries that align to the business domain.  Read the rest of this entry »

Domain Driven Design: Entities, Value Objects, Aggregates and Roots with JPA (Part 3)

Where’s the application in the demo code? There isn’t one.

If you look at the sourcecode there is no front-end, no web servlets, no screens, and no Java main class, and so no way to run it as an application. All that you can do is run the test class. So it is a library project. It is a rich “back-end” that can talk to a database.  Read the rest of this entry »