Atrenko

Clean architecture

2018-05-03T00:00:00+00:00

The principles of clean architecture have been around for years. The same goes for hexagonal and onion architectures. Sadly I don’t see it applied too often. Too bad as these principles are simple yet powerful. They lead to better design, clear separation of concerns and improved testability. This article is my attempt at evangelizing these principles.

In the picture you find an overview of the different layers in this architecture. The important thing to note here is that dependencies flow down. The infrastructure layer depends on the application layer, which depends on the domain layer. The domain layer doesn’t depend on any other layer.

If you ever read the Domain Driven Design book, these might sound familiar. However the order and content is slightly different. Let’s go over these layers in more detail.

Presentation layer

The presentation layer is responsible for all things UI. This layer contains all the necessary HTML, JavaScript and CSS files.

Infrastructure layer

The infrastructure layer is responsible for the configuration of all the technical frameworks you are using in your project. This will contain the REST controllers, the integration with SQL databases and the messaging handlers. The infrastructure layer is the only layer that should have dependencies on frameworks like Spring, Kafka client, AWS SDKs, etc.

It can provide services to the application and domain layer. The domain layer or the application layer can define an interface, which gets implemented in the infrastructure layer. This is called the dependency inversion principle.

Application layer

The application layer consists of two things.

The commands and responses the presentation layer (or other applications) can use. These are transfer objects as they can be serialized and be sent over the network. They form the public api of your application.
Command handlers. What needs to happen if your application receives a certain command?

Put differently, the application layer models the different use cases in your system. It should answer the question: ‘What can I do with this application/service/domain?’ This is not some kind of technical layer, in fact it shouldn’t have any dependency on any kind of technical framework. It describes the functionality and the flow of your system.

Avoid modelling all your use cases as methods on a single service. It will get unwieldly and it’s less clear to a future maintainer what the system is doing. Instead create a separate class for each command you handle, which represents the use case. Like a good supervisor these command handlers will mostly delegate the actual work to the domain layer.

Domain layer

The domain layer models all your business rules. This is the place where your aggregates, value objects, domain events and entities will live. Like the application layer, this should only contain plain old java objects, without any kind of dependency on other technical frameworks.

Let’s go over an example:

The presentation layer will send a request which ends up on a REST controller in the infrastructure layer. This controller will deserialize the request to a command, and pass it to the correct command handler in the application layer.

The PlaceChickenInCoopHandler command handler will look up the ChickenCoop aggregate via the ChickenCoopRepository. The ChickenCoopRepository is just an interface that gets implemented in the infrastructure layer by the SQLChickenCoopRepository.

Once the command handler looked up the ChickenCoop aggregate, it can call the placeChickenInCoop method. The aggregate is responsible for enforcing any business invariants (eg allow maximum 1 rooster in a coop). Finally the command handler will call the save method on the repository.

An important aspect of clean/hexagonal and onion architectures is keeping frameworks out of your application or domain layer. You want to avoid mixing technical concerns with business concerns, as these typically evolve at a different pace. Separating these concerns makes it easier to upgrade libraries or change technical decisions without impacting your domain too much. Vice versa, you can start modelling your business domain, even if you don’t know which database or hosting platform you will use.

It can be hard to avoid any kind of dependency in your application or domain layer. A lot of libraries and frameworks expect all sorts of annotations or interfaces on your domain objects. Try to avoid these annotations, as these tie your domain to a certain technical decision. Check if there is an alternative. Check if there is a less invasive library.

If all else fails, try to limit the dependency to just some annotations or interfaces. Just realise it is a form of technical debt. If you update or change the library, you’ll need to pay.

The same goes for in-house company frameworks! They are not exempt. Try to limit their scope to the infrastructure layer, while keeping application and domain layer as pure as possible. Don’t go too far with the DRY principle, it leads to high coupling.

Because of the separation of concerns, writing unit tests becomes very easy. You can also nicely align the different kinds of tests with the different layers in your application.

The domain layer will contain all your unit tests. Any interface that is implemented in the infrastructure layer can easily be mocked. In fact, I would only mock those interfaces, and use the real implementation of any other class in the domain layer. It’s a very clear guideline for the whole team to follow, which strikes a good balance between mockitis and integration-test-itis.

The application layer is the ideal place for your acceptance tests. Mock out the infrastructure layer but use the real classes in the domain layer. If you mock those out, you get little benefit of your acceptance tests when you refactor later on. Consider using a BDD framework here to iterate over use cases with your product expert.

Your integration tests can live in the infrastructure layer. These include full end-to-end REST tests, as well as specific integration-tests for your SQL database and messaging platforms. Don’t retest all your business cases again. Focus on testing the integration with external systems and the framework configuration.

Finally the presentation layer will contain all your Jest/Jasmine unit tests for your javascript files. You could also include your selenium tests in this project or keep those in a separate project.

Conclusion

There are many variants of clean, hexagonal and the onion architecture. Yet they all stress the importance of separation of concerns. They avoid infrastructural dependencies in the domain layer. This not only improves testability. It also allows you to postpone technical decisions till a time where you know more. While powerful, this architectural style is pretty simple. In a next post I hope to show you with a concrete example.

Big bang releases

2018-04-08T00:00:00+00:00

When replacing legacy software, a common strategy is the so called big bang release. As we saw with Argenta, this can literally lead to a big bang. In a single weekend they replaced a core legacy system with a new one. It failed miserably, resulting in customers not being able to access their bank accounts. The release at Argenta was a very public failure, but they are not alone. A lot of companies have tried and failed replacing their legacy systems in a single go. Quite often multi-million euro projects don’t even reach production. Years of development have been thrown in the trash attempting a replacement. Is there an alternative strategy?

A more agile approach to releasing consists of starting with a small release. A first minimal viable product is released in production within a couple of months. It might not have a lot of features or serve all your customers, but atleast it is live. It allows you to gather early feedback and continuously monitor the behavior. Once this version is released, you keep on extending. Every sprint you release a new increment. The smaller you can make the releases, the more you reduce the risk. Some companies release multiple times a day, in a fully automated fashion. Their releases are utterly boring, not the result of military planning or cause for celebration.

It is tricky to apply this strategy to replacing legacy systems. A first release without all the features of the legacy system is a hard sell. The solution? Don’t replace, strangle.

When you apply strangulation, you start with a release that just takes over one responsibility of the legacy system. Start with something that actually hurts, where you can create new business value.

Deploy this release next to the existing legacy system. When strangling a legacy system, the legacy system keeps running until we are sure the new system took over all responsibilities and is performing well.

We don’t want to bother the user with figuring out if he should use the new system or the legacy system. Instead we introduce a composite ui, which will show either an old legacy application screen or a new screen. Users will perceive a single integrated system, even if they notice the occasional difference between an old-fashioned legacy screen and a more modern screen of the new system.

Avoid implementing anything new in the legacy system. Instead prefer extending the new system, taking over responsibilities of the legacy system. Keep on releasing and monitor the effects and behavior. The smaller the release, the less risk there is. Note that you can prioritise on business value. You don’t need to wait until everything is replaced before you deliver something new to your customers. You can do this continuously.

If you are replacing a big legacy monolith, consider splitting it up in a microservice architecture in the new system. It will allow you to scale the number of developers working on the new system, and give you a better handle on business complexity. Apply Domain Driven Design and TDD to avoid creating a new legacy system.

A big part of strangling the legacy system, is syncing data. When you change something in the new system, you will probably need to update something in the legacy system. Vice versa, if a user updates something in the legacy system, you’ll need to notify the new system. In the next section we’ll dive deeper in this aspect.

Avoid cutting inside the legacy system itself. That’s where the dragons and unexpected behaviors are. Stay around the edges. As far as the legacy system is concerned, the new system is just another user. It doesn’t even need to “know” it has less responsibilities. Some legacy screens might no longer be in use, but you don’t need to spend the effort deleting them.

After a while the new system has taken over all responsibilities. It has proven itself by running in production continuously. Once you are there, turn off the legacy system and break out the champagne.

The same principle applies if your legacy system provides an API to other applications.

Introduce an API gateway providing the same legacy API. Gradually reimplement the legacy API by having it call the new API. New consumers of your API can directly call the new api, and take advantage of all the new features of your system. Legacy consumers shouldn’t notice anything changed.

You may never get rid of the legacy API itself (except if you have some control over all your api consumers). That shouldn’t stop you from turning off the old system.

An important part of strangulation is being able to sync data with the legacy system. Old systems might not provide a nice API for everything, or they might not notify you of all the interesting events.

You should avoid adding logic all over in the new system that handles these limitations of the legacy system. Always keep in mind the legacy system is disappearing, so you should be able to easily remove any logic that is “legacy-specific”.

Instead create an anti-corruption layer around the legacy system. It should pick up any events from the new system, and turn it into legacy commands. It should also pick up any data changes in the legacy system, and publish them as nice events on your messaging bus.

If your legacy system doesn’t publish events, you can deduce them from tracking changes in the database. There are some solutions on the market for doing this, they will for example integrate with the transaction log of your database. Google Change Data Capture for a variety of patterns and solutions.

The hard thing about syncing in a system is dealing with conflicts. If one system thinks X = 1, while another thinks X = 2, then who is right? Always consider who the master is of a piece of data. There should only be one system that is allowed to update a piece of data. They are the “master of that data”. Any other system might contain a copy of the data to do its work, but should ask the other system if they want to update it.

Initially when strangling a legacy system, the legacy system will be master of all its data. Gradually the new system will take over this role. Figure out what kind of assets the legacy system has. Step by step, asset per asset have the new system take over.

In some cases thousands of man-years went into the development of a legacy system. You can’t simply replace it in a single go without major risks. Applying the strangulation pattern allows you to reduce the risk and actually deliver business value sooner rather than later.

Serverless

2018-02-20T00:00:00+00:00

One of the most compelling movements I currently see is Serverless Architecture. So what is serverless architecture? The most interesting definition is not technical, but rather comes when looking from a financial perspective.

Typically when we are running a web application, we are billed based on capacity. We buy a couple of big servers that can handle a big load, and use maybe 10% of its power. As IT-people we like it that way, for some good reasons.

If one of the servers crashes, the other servers should still be able to handle the load.
Usage is often very peaky. For example, you might use 80% of the power when calculating invoices at the end of the month. The rest of the month our servers are pretty bored.
Adding new hardware or extra storage can take days, so we overestimate the needed capacity. Just to be safe.

This is all well and good, but if you use only 10% of the power, you are wasting 90% of your money.

Luckily the Cloud saved the day.

When you move to the cloud, we can quickly and automatically create and destroy (virtual) machines. Increasing storage is just as easy. Our capacity can more closely track the actual usage. There is less waste in this case.

We still leave some room though, not using the capacity fully. Adding a new virtual machine and setting it up might still take a couple of minutes (assuming a mature “devopsed” organisation, otherwise it can still take hours/days). We still need to handle peaks, be prepared for crashes, etc, etc. So we target an average usage of 60% and waste only 40% of our budget.

But what if we could pay based on actual usage instead of capacity?

This is what serverless is about. You don’t pay for servers or capacity in general. You pay for actual usage. In their paper Serverless Computing: Economic and Architectural Impact Gojko Adzic and Robert Chatley cover two case studies of moving to a serverless architecture. They calculated a cost reduction of 66% to 95% by adopting serverless. In a next blogpost I will cover the architectural impact and limitations (we still didn’t find that silver bullet).

A lot of the cost reductions also comes from reducing operational costs. We don’t need to buy the hardware or manage the operating system (installing updates, setting up backups, failover,…) These are provided by big cloud providers, who have economies of scale on their side. We can focus on developing and running software.

Serverless doesn’t mean there are no servers. The servers are just owned, operated and managed by Amazon, Google or Microsoft. They have built massive capacity and are sharing it accross all their customers. Isn’t that time-sharing? Maybe, but serverless sounds way cooler.

Product roadmaps relaunched

2018-02-11T00:00:00+00:00

I recently read an interesting book Product Roadmaps Relaunched. In most companies, there is a desire to create a long-term roadmap. Quite often this results in quite a few conflicts with principles of agile software development. There is little point in creating a backlog of user stories for the next 3 years and planning them sprint-per-sprint. This book describes a better way of handling things. In this blogpost, I’ll provide a short summary.

A product roadmap is fairly simple, consisting of a few elements. It is a great way to create alignment and focus within your company accross all divisions. Developers know why they are creating something. Sales knows what we can promise, and what we can’t. Product owners have an easier time prioritizing stories.

Let’s go over each element in a bit more detail.

A product vision essentially explains why the product exist. It can be summarised in one sentence:

For (customer)
Who (needs)
The (product name)
Is a (product category)
That (benefit)
Unlike (competitor)
Our product (differentiates).

It is a simple sentence, but it requires you to figure out who your target customer is, what they need, how your product will solve that need. It also requires you to figure out where your product fits in the market, who your competitors are and how you plan to differentiate from them.

You might be on the road to your ideal product vision, but how do you know you are driving in the right direction? Objectives are the goals of your product. An objective should help you measure the progress you are making towards your vision. If you release a new version of your software, what will be measurably different?

The book refers to the OKR (Objectives & Key Results) framework as a way to set these goals.

Example:

Objective: Lower costs
Key result: Software hosting cost is reduced by 30%
Key result: IT Operations cost is reduced by 90%

Note how we are focusing on the outcomes, not on the output. You might accomplish this objective by moving your software from your own datacenter to Azure and setting up a deployment pipeline using Visual Studio Online. The same could also be accomplished by moving to AWS and using Jenkins or AWS CodePipeline.

It’s also interesting to look at it from your customer perspective. How would you reduce their costs? For a data-entry application, your key result might be end-user can enter 90% of the new data in less than 2 minutes. Writing your objectives from the perspective of your customer, enables you to share the roadmap with them.

Themes describe the high-level customer/system needs and problems you are trying to address. Themes should relate back to a certain objective(s). Instead of focussing on what you are going to do, you focus on the why. The what can wait until you are actually ready to tackle the problem.

For the current quarter, you would create a concrete backlog to actually solve a theme. Themes are split up in subthemes, and subthemes are split up in stories. Because stories are related to themes, and themes are related to objectives, we can prioritize them a little easier. For each story we can estimate what impact it will have on each business objective. It’s hard to do this using absolute numbers, but t-shirt sizing works well here. The goal is to prioritise the stories relatively to eachother.

By estimating effort and risk in a similar way, you can do a simple cost-benefit analysis. This results in a nicely prioritized list of stories.

After releasing your user stories to production, you can measure how you are progressing on those key results. Maybe that minimal-viable-product was more than enough to achieve those objectives.

Don’t try to figure out what you will release on 23th June in 2038. The further in the future you look, the more uncertainty you will encounter. Will your vision remain the same? Your objectives? The needs of your customer might change, competitors might come and go. All these things will have an impact on what you will need to do.

Make sure your roadmap reflects this inherent uncertainty. You can detail what you are doing this quarter. You can describe what problems you’ll tackle the rest of the year, and what high-level issues or opportunities you see for the future.

A great way to figure out what themes to tackle first, is to create a customer journey map.

How does your customer interact with your organisation or your product? Where does it hurt the most? This is the kind of excercise that can help shape themes, timeframes and even customer objectives.

It should be clear a product roadmap isn’t something you can create once. You should revisit it regularly. Did your production releases have the expected result on your business objectives? Are those objectives still relevant? Were your effort/business value estimates realistic?

There are a lot of reasons why your product roadmap should be changed. So if you share your roadmap with your customers and stakeholders, do yourself a favor. Add a little * subject to change at the bottom.

Conclusion

Product Roadmaps Relaunched is an excellent book. It is a fairly short read and gives some great practical advice on how to create a product roadmap in an agile world. I loved how it focussed on the why. All too often I see product roadmaps that only contain the what. You end up overpromising features to the customer without actually solving their needs. This book avoids that trap.

The lead developer

2015-09-12T00:00:00+00:00

Yesterday I was at The Lead Developer conference. The talk on microservices by Russ Miles started of with a live performance of Highway to Hell, talked about Anti-fragility, DDD, CQRS and ended with a marriage proposal. Clearly this isn’t your average conference. While the technical content was great, it was the people-oriented topics that made it truly worthwhile. Here is a little summary on what I learned thanks to all the wonderful speakers.

During my last coaching talk, I got the feedback that it would help more if I try to get my colleagues to the next level. I was a bit too focused on improving my own technical skills. I’m pretty sure Camille Fournier made her talk specifically for me, elaborating on this topic. At a certain point, your technical skills are no longer your main bottleneck. It makes more sense to help your team get better, instead of trying to improve your individual productivity. Become a multiplier in your team, instead of getting a little bit better.

She tackled some of the typical mental hurdles you might encounter when making the switch. You might suffer of availability bias. The more skilled you are at something, the more important you think it is. You might fear that you’ll end up being a pointy-eared boss without any technical skills. You might not like it outside your comfort zone. I know I tend to go back to my comfort zone the moment the pressure is on.

Personally I have always struggled with this coaching aspect of my role. One reason is that I always had the idea that there was little difference between being an agile coach and being a lead developer. I did some projects as an agile coach, guiding teams through a transformation. I didn’t like it. You’re never really part of the team, needing to keep some distance. You’re not building a product, instead constantly observing and subtly guiding the team to work well together. As an introvert, this drains all my energy. Introversion can be a great power while coaching, but I have no idea how other coaches are able to recharge.

Dan North had a great talk that helped me make the distinction between coach and lead developer. As a lead developer, you are part of the team. You are building a product, figuring out how to keep it running in production. You are talking to business, figuring out the simplest way to value. When my team mates come to me with a technical problem, half the time I tell them not to solve it. I tell them to talk to the product owner and see if there is a simpler solution possible.

There are still a lot more aspects to being a lead developer. You don’t need to just lead and mentor your team, but also realize that you are part of a bigger department and organization. Teams might need to be quickly formed and rearranged. Knowledge sharing should occur across team boundaries, preferably as a natural side-effect of working. On-boarding of new people becomes very important. It might not be a bad idea if all new hires follow the same set of courses and read some of the same books. It can help creating the same shared values in an organization and reduce the time of forming/storming phases.

There is a lot more uncertainty on how to approach things as a tech lead. You don’t have simple black or white answers, you have a bunch of annoying paradoxes. Do you stay technical or do you try to enable people? Do you try to go faster or do you reserve some time for learning? Do you focus on delivering or do you try to innovate? Should you be transparent towards the team or should you help them focus by hiding The Game Of Thrones some managers like to play? Patrick Kua tried to convince me you can often do both. Which is true but I feel it is still a difficult balancing act. It’s hard to know if you struck the right balance. There was an interesting tip to do personal retrospectives, reflecting on how you did as an individual. Anyone know some cool formats for this?

There were some interesting talks on building a team. Oren Ellenbogen talked at length how you could create happy engineering teams, even if your company is scaling. His book has the beautiful title Leading snowflakes. Sam Barnes put it more plainly, People are weird, I’m weird. A common theme during the entire conference was respecting individuality, showing some empathy, and avoid hiring assholes.

The best talk on empathy and hiring came from Cate Huston. What struck me, was when she mentioned that an interview is generally the most important thing a candidate will do that day. It has potentially a massive impact on the rest of his or her career. It makes sense to treat the interview with respect. She mentioned this crazy piece of research. A prisoner is more likely to be released on parole if his judge just came back from lunch. How often do we bring our personal bias and stress to interviews? Take a little walk and clear your head before you are meeting with a candidate.

A great way to set up a candidate for success could be to give them a choice. Let the candidate choose between a coding exercise or a whiteboard exercise. If you want empowered people, shouldn’t you start at the interview? Cate also gave some great tips on setting yourself up to come across warm and friendly. It basically boils down to looking at an image of a raccoon riding an alligator ;-) She also mentioned an interesting book called The Charisma Myth. Sam Barnes’ focus on honesty during an interview was also great. We often ask the candidate for his or hers weak points. Why shouldn’t we also tell them the crappy parts of the project they are joining?

I’ve learned a lot at The Lead Developer conference. Introductions to Rust, Go, NativeScript, web optimization techniques, testing,… It really hit the sweet spot between technical and people-oriented topics. I’m looking forward to next year!