Domain Primitives - the key to creating secure code

This article is an excerpt of topics discussed in the book Secure by Design that I'm currently writing together with Dan Bergh-Johnsson and Daniel Deogun.

Domain primitives and invariants

Some of the key properties of a value object in Domain-Driven Design are that it’s immutable, it forms a conceptual whole, and it can uphold invariants and check constraints. We have found that if you take the concept of the value object and slightly tweak it, while having security in mind, you get something called a domain primitive.

Entities and Security: identity matters

This article is an excerpt of topics discussed in the book Secure by Design that I'm currently writing together with Dan Bergh-Johnsson and Daniel Deogun.

Entities

Each part of your domain model has certain characteristics and a certain meaning. Entities are one type of model object with distinct properties. What makes an entity special is that:

• It has an identity that defines it and makes it distinguishable from others.
• It has an identity which is consistent during its lifecycle.
• It can contain other objects, such as other entities or value objects.
• It’s responsible for the coordination of operations on the objects it owns.

What this means is that if we need to know if two entities are the same, we look at their identities instead of their attributes. It’s the identity of the entity that defines it, regardless of its attributes, and the identity’s consistent over time.

New Book: Secure by Design - now in early access program

The blog posts have been sparse but I've still been writing a lot lately.

After years of thoughts, discussions, and trying out ideas in real projects, we decided to formalize our views on software security in the form of a book. A privilege to write a book together with such great co-authors as Dan Bergh-Johnsson and Daniel Deogun.

Today is a big day because the first early drafts of the book is now released to the public through the Manning ”early access program” (MEAP). We still have a long way to go, and a lot of hard work ahead of us, but I'm confident it'll turn out just as good as we hope - or better.

If you’re interested in reading a book in-the-making, or just want to ’pre-order’ the finished book, you can get it for 50% off until January 24 (2017) if you use the discount code "mljohnsson" (all formats)

https://www.manning.com/books/secure-by-design

Continuous Delivery and Conway's Law

The challenges of continuous delivery

Continuous Delivery is more and more becoming a mainstream practice in how to create and deliver software. The reason for this are the numerous benefits this practice will have on the business as a whole. But as with most other things there is no free lunch and these benefits do not come without a price. An example of this is the fact that there are many challenges you may face when trying to implement continuous delivery in an existing organization. My colleague Daniel Deogun and I have spent quite a lot of time working with implementing continuous delivery practices within organizations. And in doing so we started to notice some reoccurring patterns among the challenges that organizations run into when moving towards continuous delivery.

Custom accessors with IntelliJ's new code generation features

The problem with getters

If you know your Java history, you will also be familiar with the naming conventions for accessors and mutators that was introduced, and defined, by the JavaBeans specification. (i.e. the good ol' getters and setters) This naming convention became more or less a de facto convention for accessor and mutator methods in Java. Even for objects that had no intentions whatsoever to be a java bean.
And because it was such a widespread naming convention many frameworks and libraries started to rely on that convention in order to provide useful features. Luckily, many of the popular frameworks and libraries that are used today no longer require these naming conventions in order to function.

That means that today it is perfectly fine to write code like person.name() if it makes more sense to you and you will not be forced to write person.getName() just in order to get your tooling to work.

Clean code - why it matters

Well designed and thought through code is something every software professional should take seriously as it is an enabler for so many important properties of software design. It will help you in areas such as testability, maintainability, modularity, sustainability, readability, security, time-to-market and so on. The list of positive side effects of creating well designed code is neverending.

If you are new to the term clean code, then Bob Martin's book Clean Code is a good place to start to get an inroduction to what it means. In his book, Bob Martin shows many examples of what clean code can look like and you may not agree with all of them but the importance is to understand the overall concept and purpose of the term. Other areas to explore in terms of code design is domain driven design (DDD) and test driven development (TDD).

In my view, well designed code is the foundation of everything that we do as software professionals. All contemporary best practices that we apply daily are dependent of well designed and expressive code. Whether it be TDD, DDD, domain driven security, continuous integration, scalability and so on. A poorly designed code base that is nothing more than a big mess of code will never enable you to succeed in any best-practice, at all. Period. This may sound a bit harsh but in the long run I really do believe that well designed code is the base for everything else.

MapReduce made simple with Akka

As you probably already know, Akka can make your life a lot easier when it comes to things like concurrency and scalability. A very typical use case for starting to use Akka is when you have a computation or algorithm of some sort that lends itself to parallelizing. Implementing that with just core Java is cumbersome, error prone and it will feel like you are reinventing the wheel every time you do it. Akka will, for example, enable you to take advantage of all the cores in your CPU, or maybe even the CPUs of several machines, without having to worry about the evils of things like threads, lock, semaphores etc., and not to mention the hassle of trying to distribute the computations.

Java-based configuration in Spring - An introduction

If you have not started using Java-based configuration in your Spring projects you really should take a look at it since it is a very valuable tool to master. Java-based configuration has been supported right out of the box since Spring 3.0 so it has become quite complete by now. (with the stable release being 3.2.x at the time of writing this post)
Personally, I have found that I hardly ever use any XML configuration files in Spring projects that I create nowadays. And as a side note, if I am also able to use an application server that supports Servlet 3.0 I can even get rid of my web.xml file. Thus eliminating a big part of the XML-based configuration usually needed.

Ok, but why? You might ask. Well, if you think about it there are a lot of benefits of having your configuration in code instead of in XML.