Sunday, 31 July 2016

I Need to Stop Misusing Divs

I a certainly not a skilled or expert front end developer. While I'm more than capable of creating pages I lack any design magic to make them look half decent. Despite this one area where improvement can be made is in my markup itself.

Over the past few months I've spent most of my time getting to grips with recent additions and changes in the HTML5 and CSS3 space. During this one area stood out, my misuse of the division element or <div>.

Before the addition of the newer elements pages nested with div after div was normal. However this is no longer the case. From this point onwards I will be ensuring that every time I introduce a div element I question whether a more appropriate element should be used.

The HTML div element (or HTML Document Division Element) is the generic container for flow content, which does not inherently represent anything. It can be used to group elements for styling purposes (using the class or id attributes), or because they share attribute values, such as lang. It should be used only when no other semantic element (such as article or nav) is appropriate.

Semantic Meaning

Two huge side effects that are often overlooked when ignoring semantic markup is device compatibility with screen readers or other input methods and future proofing content.

Many people wrongly assume that all users are either keyboard/mouse or mobile (touch) users. By using semantic elements, users of other input methods get a much smoother experience. It is possible to jump to navigation or content without having to page through dozens of unrelated sections added only for stylistic purposes. Having used such devices first hand, the joy such simple changes make are outstanding.

Using semantic elements also helps future proof content. Screen scraping and other technologies can be simplified massively if content is correctly marked up. The thought that pages of content written now will still be used and accessible decades from now is incredible.


The lesson here is an easy one. Every time you write a generic division element, stop and ask yourself is there an element with more semantic meaning that will do the same job?

Tuesday, 19 July 2016

Anaemic Domain Models and Code Smells

An anaemic domain model (ADM) is considered a code smell in many cases. An ADM is present when you have a entity representing your domain, but void of any behaviour. Any logic is separate and operated upon in isolation. Such domain models can be thought of as simple property bags, plain old language objects or DTO's.

Code Smells

With an ADM your behaviour ends up split across many domain services instead of being grouped with the data it operates upon.

As the domain and your understanding evolves, the problem an ADM introduces can get worse as more and more domain services are added.

A complex domain or one that evolves will end up paying a price. Converting to and from what looks like a domain model, only to perform domain logic separately is quite redundant. Why not ditch the domain model altogether? If you have a simple problem, a simple solution such as a transaction script may very well do the job.

Simple Problems - Simple Solutions

Sometimes you don't have a complex domain. Input, basic logic, then some form of CRUD is incredibly common. Due to this it is easy to see why anaemic models exist.

Rather than the cost associated with attempting to model the domain, choose easier solutions such as transaction scripts, table gateways or similar.

The big argument for anaemic domain models is following the SRP. Adding behaviour to domain models does not violate SRP. There is no reason why such additions cannot be formed from composition or delegation. Likewise the internal representation can be private. On the flip side domain services operating under the disguise of SRP lack cohesion, despite doing one thing.

The good news is that the ADM is very easy to extend and refactor at a later point. Moving to a richer domain model is not difficult, though the process may take time.

Refactoring from an ADM

Simply push behaviour onto entities, one method at a time. As you do this, services will begin to dissolve. All of this can be done when supported by a good suite of tests.

An equally simple step is to being introducing value types. Over time these will act as code magnets pulling any related behaviour towards them.


  • In most cases an ADM is a code smell.
  • There may be easier solutions than a anaemic model that mimics your domain.
  • The ADM is not a good example of SRP.
  • Refactoring towards a rich domain model is easy and achievable at any stage.

Sunday, 17 July 2016

UI Composition Techniques for Services

When using services be it SOA, microservices or some other hybrid approach, at some point you will need to display an aggregation of data onto a UI. This simple task can actually involve some complexity and hidden pitfalls.

As an example, this blog could be powered by three independent services. A comment service, a post service and a archive service. Displaying this content on the page could involve a few different approaches both with pros and cons. Each vary in terms of benefits and complexity.

  • Service Composition
  • Server Side Composition
  • Backends For Frontends
  • Frontend UI Composition

Service Composition

Composition within independent services should be avoided at all costs. In these cases service A invokes service B which invokes service C, which has a dependency on A and so on. The problems such composition introduce defeats any benefits that a service based approach brings. In short composing data in this manner will lead to problems.

Server Side Composition

Invoke each service behind a single request and perform composition on the server. Return the results of the aggregation which can then be processed by the UI. In most cases a request will be a request over HTTP.

  • Single request to fetch all data.
  • Single server side place to change if UI requirements change.
  • Forms an anti corruption layer in front of the independent services. Client specific changes do not leak down into the service.
  • Coupling is moved to the server side. Harder/slower to change compared to HTML/JS/UI layer.
  • Handling failures must be considered more so than client side composition.
  • Timeouts or lack of responses must be considered using asynchronous techniques.
Where Does The UI Live?

Due to the nature of having to serve up data for the UI layer to consume, it makes sense to purely store the UI components within the host application. In this case the whole host application will use the same UI techniques.

Backends For Frontends (BFFs)

An alternative which builds upon server side composition is server side composition but performed individually based on the UI required. In other words, a set of server side applications for each host are created.

As UI clients can differ drastically a single server side composition technique may not be sufficient. Mobile devices may require a slimmed down version of data, while desktop dashboards may prefer large quantities. Additionally it is quite common to find certain clients asking for additional fields or requirements specific to their client implementation. In these cases BFFs make a great deal of sense.

  • Same pros as server side composition.
  • BFFs allow full control of server side composition tailored to the clients.
  • Specialized BFFs reduce change and prevent independent services handling UI specific edge cases.
  • Same cons as server side composition.
  • More moving parts, though BFFs should be owned by the client themselves for true autonomy.
Where Does The UI Live?

The same guidance as server side composition stands. Where the actual BFF lives depends on how it is used. If the mobile client is expected to have multiple implementations then a standalone service would be required. Alternatively if only a single mobile platform is targeted, then the service could live within the host application itself.

Frontend Composition

Invoke each service and display its data independently via the client. The host application will include the front end of each service by conforming to a common standard such as Javascript or other UI components. The use of IDs and client side identifiers will be required to ensure all services are linked in some manner.

  • Failure tolerant by default, if a single request fails the others carry on processing.
  • JS/UI layers make asynchronous calls easy, composition is a natural fit.
  • Weakest form of coupling is in the UI layer - easier and cheaper to change.
  • Flexible as you can create mash ups that would otherwise violate service boundaries.
  • Multiple requests to fetch content (four HTTP requests using the blog example above).
  • Aggregation may be complex. You may need to use more than just plain Javascript or face complex, coupled JS.
  • Depending on where the UI layer is stored, you may be coupled at the UI level due to the same framework or approaches needed across each service.
Where Does The UI Live?

Storing the UI within each service is ideal on paper, but in practice has some limitations. Each service can vary and iterate at its own pace which is fantastic as long as the integration of the service remains unchanged. Unfortunately the downside is that each service is actually independent in terms of the UI. This means that versioning the front end component becomes an issue. Likewise there is nothing stopping different services using different libraries or frameworks. If the UI component requires any server side additions this becomes even harder. For example a host application written in one language will be incompatible with other services if they differ. The final issue relates to storing UI components outside of host application frameworks. Many frameworks simply make this either impossible or very difficult to achieve.

Using the host application to store the UI components side steps the disadvantages and issues above. While you are at the mercy of the host application to integrate each component, this is not a show stopper. Chances are most applications have multiple views, so a single UI component would never be reusable across applications. Additionally the use of thin vertical slices should mean that even though the UI component is physically separate from the service, there is no reason why the two cannot be worked on in conjunction.

A final factor to consider is that there is no reason why a hybrid approach cannot be taken. Each service should store its own UI component, but also allow host applications the ability to integrate. This UI component can act as a form of dog fooding as well as providing an excellent development and test bed. It is far easier to work and test a small widget with an automated test than it is to exercise this within the context of a full blown application.


  • Avoid the use of internal service composition - remote calls to third parties being the obvious exception to this rule.
  • There is no best approach overall, the chosen solution will vary based on application.
  • Server side composition has benefits, but client side UI composition opens up new possibilities.
  • Client side composition seems more complicated but in reality it is merely different, though does require some up front planning.
  • Default to using the services directly, only introducing a BFF if client requirements differ or client requirements are being forced upon the independent services.

Sunday, 10 July 2016

Notes on Building and Deploying Software

Builds and Deploys

Ideally a build and deploy should be a single step, included within the check out of the repository. Additionally the build should include and install pre-requisites if missing. You can safely assume the target OS is at least configured, but any missing packages should be installed as needed.

The core steps regardless of platform or technology follow a common pattern. A number of these steps can be performed asynchronously. For example, it is possible to run a suite of tests in parallel, rather than individually. This can save massive amounts of time. As a first approach perform all steps synchronously, only adjusting once stable.

  • Compile/Lint - Sync
  • Run Unit Tests - Async
  • Deploy - Async
    • Warm up (cache hits, web server)
    • Data (run migrations)
    • Configuration
    • Host Environment
  • Run Integration/Acceptance Tests - Async

This whole process should be executed regardless of environment. A local developer machine only differs to production in terms of topology. If you cannot execute the exact same process that you are performing upon commit, you can never be sure the commit will work. CI tooling should act as nothing more than an aggregation of stats and artefacts that are generated by invoking the build/deploy script.


A working software application can be decomposed into four components.

  • Executable code - your application.
  • Configuration - connection strings or credentials.
  • Host environment - target deployment machine.
  • Data - required data for use, or persistent stores such as databases.

If any of these change, trigger the feedback process as they can all change the behaviour of the application.


  • Aim to automate everything, but do it gradually over time. Aim for the bottlenecks to begin with if the task of automating the deployment pipeline is daunting.
  • Keep everything in source control. Never allow your CI tool to control your pipeline.
  • Don't check passwords or credentials into source control.

Speed is Key

  • Too long and people wont commit often.
  • Under thirty seconds is ideal. Faster is better.
  • Fail the build if the time exceeds a set threshold. You can use ratcheting to reduce this over time.
  • Monitor tests regularly and try to speed the slowest ones up.

Build and Deploy Etiquette

  • Don't check in on a broken build, unless you are fixing it.
  • Perform an update prior to commit and run the whole build/deploy process.
  • Never go home on a broken build, and ideally don't check in just before leaving.
  • Never deploy on Friday's or whenever there will be few developers around on hand, such as holiday periods.
  • Always be ready to revert to the previous version. If the fix takes longer than just simply reverting the changes, don't try and fix the build. Just revert.
  • Fail the build for architectural breaches such as a module referencing a module it shouldn't.
  • Fail the build for warnings or code style breaches. Warnings can hide serious problems.


  • Lock down production environments.
  • Treat test environments equally, these should also be locked down from manual changes.
  • If you cannot create your infrastructure from scratch via an automated process to begin with, implement access control so that any changes must be requested and logged.
  • Any changes should be back filled and tested. Use some form of audit or access control to manage these steps.


  • Use migrations to manage data. Have a version table that stores the schema version. Use migrations to roll forwards or roll back incrementally.
  • Each migration should have an "up" and a "down" step. For example, up adds a table, down removes it. Run these both before committing to make sure they work.
  • Migrations allow you to decouple the deployment of your application from the deployment of your database.
  • The use of views or stored procedures can add a layer of abstraction between applications and databases. This allows changes to the underlying DB to have a smaller, limited effect.