Saturday, 23 January 2016

Testing Without Objects - I Like It

Unit testing behaviours that depend only on functions has been a revelation for me. Without the labour of having to mock objects, I find creating tests easier and feel more satisfied with the resulting code which is cleaner, clearer and at-least as expressive.

I'm not here to bash OO or to promote the one true way. With demonstrative code examples I am instead going to continue where I left off in my last post explaining the benefits I am seeing from composing applications mostly of functions and with fewer objects.

Last time I demonstrated the benefits of using just functions and data to create application services. This post shows their benefits on unit testing.

Saturday, 12 December 2015

Functional Application Services

Each business use case or key transaction in your application can be modelled as a unique, explicit application service. Modelled this way, and named as verbs, application services accentuate key business concepts - improving the alignment between your problem domain and codebase.

The traditional object-oriented approach to application services is now being outshone by functional approaches. Functional application services are more explicit, more concise and more maintainable - especially in functional languages like Scala.

In this post I’ll take you through an example of how I’m doing application services in Scala. The concepts are beginner-level functional programming, though they are definitely a stepping stone toward deeper functional patterns and concepts.

Note: A sample application to accompany this post is on my github. For a similar blog post demonstrating this pattern in C# I highly recommend checking out Mike Hadlow's blog.

Sunday, 15 November 2015

API Testing Patterns for the Play Framework

A robust suite of end-to-end tests for your APIs gives you the confidence to iterate and move quickly. With APIs being easier and faster to test than web frontends, the invaluable benefits of testing come at a low cost of investment.

Two of the key challenges when creating API tests are expressing the desired system-level behaviors precisely and, more technically focused, deciding how to cover external dependencies.

After a few years of working with the Play Framework I’d like to share a few of the testing patterns I am using to both solve the challenges just mentioned and create tests effortlessly and productively.

Sample code to accompany this blog post, including a vagrant dev environment, is available on my github.

Wednesday, 21 October 2015

Strict JSON Deserialization with Enum Validation

It's important to validate data sent to your APIs. Silently ignoring unrecognised fields or not detecting and rejecting values outside of the allowable range is a dangerous way for errors to go undetected.

Clients will be calling your API, getting a 200 response and blissfully assuming everything is wonderfully integrated. Enraged customers will eventually find the problem and it won't result in you getting a pay rise.

These risks are especially inherent to JSON APIs. With XML we have XSDs to enforce the schema. We haven't quite got there with JSON yet, so it's vital to be extra vigilant in your code.

I recently found out that it's actually not as easy as it should be to reject unrecognised JSON fields and out-of-range enum values in Scala (using the Play Framework).

Thursday, 8 October 2015

Sharing Databases Within Bounded Contexts

A contentious topic in distributed systems is if/when/how to share databases. Some developers/architects will tell you never to do it. Others, like me, will cautiously mention a few acceptable scenarios.

"Components [within a bounded context] work together very closely; therefore, having shared dependencies increases cohesion... without necessarily causing problems"

Patterns, Principles and Practices of Domain-Driven Design

Who is right? What is the one true way?

In this blog post I won't be wasting time on such futility. Instead I’ll be elaborating on my belief that sharing databases, and other dependencies, within bounded contexts can be sensible and savvy.

Thursday, 10 September 2015

Please Use The Cascade Rule

Amongst all the hype of shiny new technologies, fashionable working practices and clever design patterns, sometimes I think the absolute basics of writing readable code are ignored or discarded as boring. I can’t think of a more saddening example than the unloved cascade rule.

Please can we use the cascade ruuuule?

We write code from left-to-right because we read left-to-right. Our eyes go from the left of the screen to the right, and then down to the start of the next line. It’s easy and comfortable because that’s how we read books and articles.

Logically, then, we should write code that reads from top-to-bottom since our brains are trained to read that way. That's all there is to the boring-but-effective cascade rule. It makes code easier to read and I love it.

Saturday, 15 August 2015

Domain-Driven Architecture Diagrams

Domain-Driven Design is about creating shared understanding of the problem space that is reinforced ubiquitously via conversations, code and diagrams. DDD’s Shared understanding enhances synergy and alignment, increasing the ability to deliver value sustainably - ideally over the lifetime of a product.

As I most recently attempted to justify at the London Women Who Code Intro to DDD Architecture workshop, the architecture of a system, expressed via diagrams, is a profitable avenue for reinforcing DDD’s shared model.

Highlighted in red: where architecture diagrams can be advantageous using a domain-driven approach.
Diagram modified and borrowed from Patterns, Principles and Practices of Domain-Driven Design published by Wrox