Local-name annotation

Have your tools accept any annotation as long as its single name (without the fully-qualified prefix) is the expected one. For example com.acme.NotNull and net.companyname.NotNull would be considered the same. This enables to use your own annotations rather than the one packaged with the tools, in order not to depend on them.

Example in the Guice documentation:

Guice recognizes any @Nullable annotation, like edu.umd.cs.findbugs.annotations.Nullable or javax.annotation.Nullable.

Composed annotations

Annotations can have annotations as values. This allows for some complex and tree-like configurations, such as mappings from one format to another (from/to XML, JSon, RDBM).

Here is a rather simple example from the Hibernate annotations documentation:

@AssociationOverride( 
   name="propulsion", 
   joinColumns = @JoinColumn(name="fld_propulsion_fk") 
)

Multiplicity Wrapper

Java does not allow to use several times the same annotation on a given target.

To workaround that limitation, you can create a special annotation that expects a collection of values of the desired annotation type. For example, you’d like to apply several times the annotation @Advantage, so you create the Multiplicity Wrapper annotation: @Advantages (advantages = {@Advantage}).

Typically the multiplicity wrapper is named after the plural form of its enclosed elements.

Example in Hibernate annotations documentation:

@AttributeOverrides( {
   @AttributeOverride(name="iso2", column = @Column(name="bornIso2") ),
   @AttributeOverride(name="name", column = @Column(name="bornCountryName") )
} )

Meta-inheritance

It is not possible in Java for annotations to derive from each other. To workaround that, the idea is simply to annotate your new annotation with the “super” annotation, which becomes a meta annotation.

Whenever you use your own annotation with a meta-annotation, the tools will actually consider it as if it was the meta-annotation.

This kind of meta-inheritance helps centralize the coupling to the external annotation in one place, while making the semantics of your own annotation more precise and meaningful.

Example in Spring annotations, with the annotation @Component, but also works with annotation @Qualifier:

Create your own custom stereotype annotation that is itself annotated with @Component:

@Component
public @interface MyComponent {
String value() default "";
}

@MyComponent
public class MyClass...

Another example in Guice, with the Binding Annotation:

@BindingAnnotation
@Target({ FIELD, PARAMETER, METHOD })
@Retention(RUNTIME)
public @interface PayPal {}

// Then use it
public class RealBillingService implements BillingService {
  @Inject
  public RealBillingService(@PayPal CreditCardProcessor processor,
      TransactionLog transactionLog) {
    ...
  }

Refactoring-proof values

Prefer values that are robust to refactorings rather than String litterals. MyClass.class is better than “com.acme.MyClass”, and enums are also encouraged.

Example in Hibernate annotations documentation:

@ManyToOne( cascade = {CascadeType.PERSIST, CascadeType.MERGE}, targetEntity=CompanyImpl.class )

And another example in the Guice documentation:

@ImplementedBy(PayPalCreditCardProcessor.class)

Configuration Precedence rule

Convention over Configuration and Sensible Defaults are two existing patterns that make a lot of sense with respect to using annotations as part of a configuration strategy. Having no need to annotate is way better than having to annotate for little value.

Annotations are by nature embedded in the code, hence they are not well-suited for every case of configuration, in particular when it comes to deployment-specific configuration. The solution is of course to mix annotations with other mechanisms and use each of them where they are more appropriate.

The following approach, based on precedence rule, and where each mechanism overrides the previous one, appears to work well:

Default value < Annotation < XML < programmatic configuration

For example, the default values could be suited for unit testing, while the annotation define all the stable configuration, leaving the other options to  configure for deployments at the various stages, like production or QA environments.

This principle is common (Spring, Java 6 EE among others), for example in JPA:

The concept of configuration by exception is central to the JPA specification.

Conclusion

This post is mostly a notepad of various patterns on how to use annotations, for instance when creating tools that process annotations, such as the Annotation Processing Tools in Java 5 and the Pluggable Annotations Processors in Java 6.

Don’t hesitate to contribute better patterns names, additional patterns and other examples of use.

EDIT: A related previous post, with a focus on how annotations can lead to coupling hence dependencies.

New languages to have a look at (my own selection)

Based on what I read everyday in various blogs, I arbitrarily reduced the list of candidates to just a few language that I believe are rising and promising:

• Scala
• F#
• Clojure
• Ruby
• Groovy

Of course each language has its own advantages, and we should definitely take a look at several of them, not just one. But the popularity of the languages is also important to have a chance of using them in your day work.

Growth rates stats

In order to get some facts about the trends of these new programming languages in the real world, Google trends is your friend. Here is the graph of rate of growth (NOT absolute numbers), worldwide:

I’m impressed at how Clojure is taking off so brutally… In absolute terms, Ruby comes first, Groovy second.

So that was for the search queries on Google. What about the job posts? Again these are growth rates, not absolute numbers, and with a focus on the US.

Scala, F#, clojure, Ruby, Groovy Job Trends

Scala jobs - F# jobs - Clojure jobs - Ruby jobs - Groovy jobs

Again, the growth of Clojure is impressive, even though it remains very small in absolute terms, where Ruby comes first, followed by Groovy.

Popularity index

So far the charts only showed how new languages are progressing compared to each other.

To get an indication of the actual present popularity of each language, the usual place to go is at the TIOBE indices (last published June 2010):

The TIOBE Programming Community index gives an indication of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. The popular search engines Google, MSN, Yahoo!, Wikipedia and YouTube are used to calculate the ratings.

In short:

• Ruby is ranked 12th; Ruby is kinda mainstream already
• LISP/Scheme/Clojure are ranked together 16th, almost the same rank than in 2005 when Clojure did not exist yet.
• Scala, Groovy, F#/Caml are ranked 43, 44 and 45th respectively

Conclusion

Except Ruby, the new languages Scala, Groovy, F# and Clojure are not yet well established, but they do progress quickly, especially Clojure then Scala.

In absolute terms, and within my selection of languages, Groovy is the more popular after Ruby, followed by Scala. Clojure and F# are still far behind.

I have a strong feeling that the time has come for developers to mix alternate syntax in addition to their legacy language (Java or C#), still on top of the same platform, something also called polyglot programming. It’s also time for the ideas of functional programming to become more popular.

In practice, these new languages are more likely to be introduced initially for automated testing and build systems, before being used for production code, especially with high productivity web frameworks that leverage their distinct strengths.

So which one to choose? If you’re already on the JVM, why not choose Groovy or Scala first, then Clojure to get a grasp on something different. If you’re on .Net, why not choose Scala and then F#. Ad if you were to choose Ruby, I guess you would have done it already.

As for our overall impression: if you happen to go to Shanghai, you may go see the Expo 2010, but don’t plan to go there just for that. Just as Adam Minter noted in his blog (quite useful to prepare how to visit the expo):

if you’ve traveled internationally, there’s absolutely nothing inside of any of the pavilions that you haven’t seen before

This sums up our visit quite well, I was almost disappointed in fact.

Huge spaces, huge queues

For the two days we’ve been there, the queues were absolutely terrific, up to 3h30 for the Japan pavilion and the Oil 4D movie for example, and just a bit less for the most demanded pavilions. This also means we did not visit them, waiting that long is not our cup of tea.

The 3 days tickets were no longer available, we could only buy tickets for the day, not even for the next day, meaning you have to buy them each morning. Many shops that advertise they sell tickets no longer have any (we are talking 20 days after the official opening).

We also had the feeling that the Expo definitely targets only Chinese citizens, not foreigners, for example the movies have no subtitles.

Big big thanks to all the volunteers in the Expo!  These young girls and boys that speak English are all really nice and helpful, they are the real -and only- face of the Expo, and they make the huge and rather unfriendly outdoor spaces easier to deal with. And you know what? They are not paid, but they don’t even have the right to visit themselves, apart from buying their own ticket… (at least they told me that when I asked)

Our favourite pavilions

The Dutch pavilion is my favourite, with its crazy little town in the air.

The Dutch pavilion

Each house in this weird village features interesting works by artists and designers, and the ground level is free and offers a place to rest on the fake grass. The principle of the “main street” with a continuous flow of visitors just means you don’t have to wait in a queue, and the view all around is beautiful, especially at the top.

The Australian pavilion is also great, for the humour of the static presentation, and also for the show which is both technically fascinating and is one of the few to address the theme of the Expo: “better city, better life”.

In this pavilion again, the continuous flow of visitors plus a smart way to enter and exit the theater makes the queue not much of a problem.

The General Motors pavilion offers a nice anticipation of what the future of the car might be, at least in countries like China, where everything is possible. Queue time was between 1h down to 20mn when we eventually visited it. I did appreciate how a brand like GM had the courage to present such a technical dream, although it reminds similar ideas from Toyota. The queue time remains reasonable thanks to no less than 4 theaters operating at the same time around a shared stage.

The pavilion of Denmark (also continuous flow, hence no queue) is nice, with its little mermaid and the funny presentation of “how we live in Denmark” (rather weird to be honest), and its crazy and convoluted bench, and again a great view at the top.

Other pavilions with not much queuing that we enjoyed: Vietnam (skinned with bamboo), New Zealand (again a continuous flow, also addresses the theme with the question: “what is better life”), Nepal (smart design in two phases, where not many people actually go to the second phase, another good idea to reduce the queue), Cuba (smart small pavilion, with just a good bar where you can buy a good drink), State Grid (with its immersive video cube), Japan Business (promotional but not too bad), CSSC (exhibition about sea ships now and in the future), and the Czech pavilion where everything is presented on the ceiling.

And a special mention for the North Korea pavilion, self-entitled “Paradise for People“, which is a summum of kitsch with its fountain and a “back to the 80’s” institutional video. Hard to explain that feeling…

And now some pictures in random order.

Architectural madness

If you like architecture, and we do, then on the outside the Expo offers a real-size gallery of architects dreams. Each pavilion is usually built to last 6 months and must be impressive enough yet green enough at the same time. The most common strategy used to that end makes use of a thin skin of something (anything lightweight indeed) to wrap a more conventional or temporary construction.

Pavilions that I find especially beautiful from the outside are the pavilions of Spain (with large petals made of small wood branches), Emirates (all golden metal), South Korea (geometric volumes in laser-cut aluminium), Australia, Germany, UK (always looks like 3D rendering, even for real), Vietnam (bamboo), Denmark, Canada (all skinned in wood), Russia, Estonia (colourful), Mexico (with the wings), Portugal (a nice mix of natural cork and red neon) and Luxembourg (looks like a monster house).

Movies and LED screens everywhere

World Expo are supposed to demonstrate stuff never seen before, or at least impressive and novel techniques and ideas; we must be very bored then, or there is nothing novel left today (which I don’t believe so), or novel things are too complex to explain or too abstract to demonstrate, or perhaps we already know everything thanks to the Internet, but every major pavilion is more or less entered around a show in a theater using immersive techniques such as 3D and every possible kind of screen madness.

LED technology is also the grand winner of the Expo 2010, with giant LED screen everywhere outside and inside each pavilion. Video-projection resists, with some video-mapping techniques, but has already lost the battle.

Cheers,

La chaine de montagnes Huang Shan (Montagne Jaune) est un site avec des paysages absolument fabuleux. Cette beaute se merite avec ses pieds, au prix d’une ascension de pres d’une journee. Nous avons passe la nuit en haut pour pouvoir assister au fameux lever de soleil qui apparait au dessus de la mer de nuages, un spectacle vraiment magnifique. Et au retour nous avons fait escale dans le petit et charmant village de Hongcun.

Maths (cont’ed)

Abstract algebra

Another classical example of mathematical concept that I find insightful for modeling is the concept of Group in the field of Abstract Algebra. To be honest, I’d guess this is what Eric Evans had in mind when he talks about Closure of Operations (where it fits, define an operation whose return type is the same as the type of its arguments) or when he mentions arithmetic as a known formalism:

Draw on Established Formalisms, When You Can [...] There are many such formalized conceptual frameworks, but my personal favorite is math. [...] It is surprising how useful it can be to pull out some twist on basic arithmetic.

The usual integer numbers and their addition operation is an example of Groups that everybody knows (although integers are also examples of other kind of algebraic structures).

Limits as Special Cases

Going further, the concept of zero and of limits such as infinity can be inspirations for your domain. Consider for example the domain element Currency, with values EUR, USD, JPY etc. Traders can typically request to monitor prices for one currency, but they can also request to see all currencies or none.

Just like mathematicians do when they invent limit concept such as infinity or zero (a special value that does not really exist in the world but that is convenient), we can expand Currency with the Special Case values ALL and NONE, each with their own special behavior, i.e. behave like any currency or none at all (typically this means their methods return true or false respectively all the time). Trust me, it is very convenient.

You’ll recognize that the Null Object pattern generalizes the very concept of zero for arbitrary concepts.

Principles

Dimensions in the domain

Something I clearly learnt from maths classes at school is thinking in separate dimensions, and how looking for orthogonal dimensions helps tremendously.

Given a cloud of concepts spread over the whiteboard, if you can sort them out onto 1, 2 or 3 separate dimensions (the less the better), and if these dimensions are orthogonal (independent to each other), then your design gets greatly enhanced, provided of course it still makes sense in the domain.

For example we may have a dimension that groups the concepts of user, user group and company, that is probably orthogonal to another dimension that groups the concepts of financial instrument, product segment and market. Once the two dimensions are identified, we’ll seldom discuss concepts from both dimensions at the same time, because we know that they are independent.

Yet simple, the formalism of dimension is valuable as an inspiration for supple design. Also once you think of explicit dimensions you may consider extrapolating known concepts such as ordering or interval, if they make sense for your domain. In other words your domain gets more formal, which at the end of the day, once coded, will means less code and less bugs.

Symmetries in the domain

This chair has 4 identical legs: lots of symmetries

One of the biggest possible inspiration for Supple Design is the idea of symmetry, as Paul Rayner quotes from Eric Evans in the 5th part of his series: Domain-Driven Design (DDD) Immersion Course – Part #5

Use symmetry as principle of Supple Design

I love this idea! Indeed, great physicists like Murray Gell-Mann have discovered a lot guided by symmetry.

When you look at elements of the domain, you can choose to focus on how we deal with them, rather than looking at what they are. Considering each perspective in turn helps to find out what properties the domain elements may have in common (for more see don’t make things artificially different).

Sometimes concepts looks fundamentally different just because some of them are singular whereas other are plural. The Composite pattern offers a solution for that. You can unveil symmetry just by looking from the right viewpoint.

Deeper insight than the domain experts?

Domain-Driven Design advises that the domain shall not deviate from concepts and ideas that the users really know and really talk of. However it may happen that by analysing the domain you uncover structures than the people in the business are not even aware of. In fact they may well manipulate the structure in practice without being conscious of them.

I’ve come across such a case in interest rates derivatives trading, where swap traders think of spreads and butterfly as products by themselves, and intuitively know how to combine them for their purpose. However when you want a machine to manipulate these products, you’d better formalize a bit the concepts, that are otherwise intuitive. In our case, simple linear combinations proved to be a good formal framework for spreads and butterflies, even though hardly any traders speaks of the topic like that.

Influences everywhere

I recommend browsing various fields for behaviours or structures that look similar to the domain being modelled. This yields benefits even if you don’t find a corresponding structure, since when you compare your problem to another one you must ask good questions that will help get insights anyway.

With some practice you may even anticipate, and whatever concept you encounter gets automatically “indexed” in your brain just in case you would need it later. No need to remember the concept, just that it exists.

What’s important is not that you know everything, there are books and Wikipedia for that. What’s important is to be ready to dedicate some time looking for a formalism that is well-suited for your domain.

The more demanding you are when making the Design Supple, the more reward you’ll get over time, and by this I mean less ad hoc adjustments, error corrections and tricky handling of special cases.

When a common formalism fits the domain well, you can factor it out and adapt its rules to the domain.

A known formalism can be reused as a ready-made, well understood model.

Obvious sources of inspiration

Analysis patterns

It is quite obvious in the book, DDD builds clearly on top of Martin Fowler analysis patterns. The patterns Knowledge Level (aka Meta-Model), and Specification (a Strategy used as a predicate) are from Fowler, and Eric Evans mentions using and drawing insight from analysis patterns many times in the book.

Reading analysis patterns helps to appreciate good design; when you’ve read enough analysis patterns, you don’t even have to remember them to be able to improve your modelling skills. In my own experience, I have learnt to look for specific design qualities such as explicitness and traceability in my design as a result of getting used to analysis patterns such as Phenomenon or Observation.

Design patterns

Design patterns are another source of inspiration, but usually less relevant to domain modelling. Evans mentions the Strategy pattern, also named Policy (I rather like using an alternative name to make it clear that we are talking about the domain, not about a technical concerns), and the pattern Composite. Evans suggests considering other patterns, not just the GoF patterns, and to see whether they make sense at the domain level.

Programming paradigms

Eric Evans also mentions that sometimes the domain is naturally well-suited for particular approaches (or paradigms) such as state machines, predicate logic and rules engines. Now the DDD community has already expanded to include event-driven as a favourite paradigm, with the  Event-Sourcing and CQRS approaches in particular.

On paradigms, my design style has also been strongly influenced by elements of functional programming, that I originally learnt from using Apache Commons Collections, together with a increasingly pronounced taste for immutability.

Maths

It is in fact the core job of mathematicians to factor out formal models of everything we experience in the world. As a result it is no surprise we can draw on their work to build deeper models.

Graph theory

The great benefit of any mathematical model is that it is highly formal, ready with plenty of useful theorems that depend on the set of axioms you can assume. In short, all the body of maths is just work already done for you, ready for you to reuse. To start with a well-known example, used extensively by Eric Evans, let’s consider a bit of graph theory.

If you recognize that your problem is similar (mathematicians would say isomorphic or something like that) to a graph, then you can jump in graph theory and reuse plenty of exciting results, such as how to compute a shortest-path using a Dijkstra or A* algorithm. Going further, the more you know or read about your theory, the more you can reuse: in other words the more lazy you can be!

In his classical example of modelling cargo shipping using Legs or using Stops, Eric Evans, could also refer to the concept of Line Graph, (aka edge-to-vertex dual) which comes with interesting results such as how to convert a graph into its edge-to-vertex dual.

Trees and nested sets

Other maths concepts common enough include trees and DAG, which come with useful concepts such as the topological sort. Hierarchy containment is another useful concept that appear for instance in every e-commerce catalog. Again, if you recognize the mathematical concept hidden behind your domain, then you can then search for prior knowledge and techniques already devised to manipulate the concept in an easy and correct way, such as how to store that kind of hierarchy into a SQL database.

Don’t miss the next part: part 2

• Maths continued
• General principles

Why reuse?

We want to reuse prior work or knowledge for several reasons:

1. It is easier to reuse than to redo the effort that would lead to the same result.
2. We want the best result, and the simplest way to ensure that is to reuse the solution considered to be the best in its field.
3. We want to keep something in only one place, following the DRY principle.

Ready-made reuse

Circuit-bending is about reusing old toys to create weird musical instruments

Reuse is often assumed to mean code reuse, or at least reuse of something already written:

• API, library or framework: code is packaged to be easy to (re)-use, and perhaps easy to customize.
• Code snippet: example code is provided for copy-and-paste inclusion into the code under construction. Code snippets can also be tweaked.
• Declaration files templates: many frameworks or build tools supply declarations files that can be either reused and tweaked, or imported and modified through some inheritance mechanism, such as Ant build files.
• Aspects: Aspects isolate how to address cross-cutting concerns, and can be reused as coded aspects in AspectJ for example. However applying the aspect must be done by the developer.

Ready-made reuse is the simpler kind of reuse: take it and use it, as it is. It is a no-brainer. The drawback is that this cookie-cutter approach lacks flexibility to adapt to each particular case, unless you leave the road and start to customize at your own risk.

Ready-made API’s often try to workaround this lack of flexibility through extensive options of configuration.

Reuse of ideas

However there is another kind of reuse, in the form of ideas to apply each time into the project under construction. This knowledge prepared and canned in advance can take various forms:

• Algorithms: an algorithm is often reused without code reuse, by applying the algorithm on the particular data structure at hand.
  
• Patterns: patterns are an obvious mean of reuse, and most of the time they must be applied into the code in progress, rather than imported through an API or through libraries.
• Specifications: knowing the “what to do” can also be reused, we can reuse specifications. This is especially true when re-building from scratch an existing legacy application: the legacy application can be reused as a working piece of specification, rather than reusing its actual code (which we usually do not want to reuse).
• Issues History: the history of issues already encountered and stored in a bug tracker has value for reuse too, because it can be considered a check list of possible traps when refactoring or when starting another similar project.

When reusing ideas, you have to think deeper, which is good for your brain. But because you have to take decisions to apply each idea you reuse, it takes more time and more effort, and the end result will also depend more closely on your design and coding skills.

But on the other hand, you get the maximal flexibility, or how to build the solution that perfectly matches the needs of each particular situation. This is invaluable, and this is why ready-made reuse is not always desirable.

Automated reuse of ideas

When ready-made reuse is not desirable, it may remain desirable to automate the process of applying codified ideas to a project under construction. The twist here is to reuse the process of applying ideas, rather than the ideas themselves.

Several examples of this approach already exist:

• Code generation, method and field injection: generation and injection of code is a process to enable reuse of prior knowledge and effort, concentrated into a generator. For example in the tool JiBX, the knowledge of how to serialize beans into XML is canned into a bytecode generator.
• Macros and C++ templates: just like code generation, macros and templates are processes that apply codified ideas to program elements in an automated fashion. Note that this is not the case with Java or .Net generics, which are just plain (generic, really) code reuse.
• Middleware magic: interception, dynamic proxies and other decorators created behind the scene by most JEE application servers are a form of reusing ideas by applying them to each specific entity or service.
• Compiler or VM optimization: automatic compiler optimizations have removed the need to manually optimize code for most cases, thanks to automatic application of many optimization techniques.

If we want to automate further the application of ideas onto code, we need better ways to guide the tools. For a tool to apply an idea onto existing code, you need to describe what you want to the tool. If the required amount of user input is excessive or if it is impossible to tell a tool your intent, you’d better of doing the work manually. This is the limiting factor toward more powerful tools.

More explicit, more reuse

By making intents and concepts more explicit in the code, tools can increasingly automate tasks that otherwise would remain manual tasks:

• Maven POM: Maven makes project information explicit in its project object model (POM), and as a result each plugin can configure itself. A plugin that needs to know where to find the source code files can access the information by itself, and this can be seen as a reuse of a predefined configuration. In contrast, with Ant you must configure the information repeatedly for each task.

Imagine now a cross-cutting concern “Auditability” which requires to “record every action that changes the state of an entity”.

In other words we need to record every action that is not safe, as defined in REST. If we can explicitly declare on each operation and service whether it is safe or not (e.g. using annotations), then a tool can automatically weave a predefined Aspect for Auditability, without any specific configuration.

This example illustrates how we can reuse both the aspect (ready-made reuse) and the configuration of its pointcuts (i.e. reuse of the process of applying the aspect), thanks to a new concept (Safe) made explicit in the code.

I believe there are still many other forms of knowledge that could be reused automatically, and this looks like an exciting area of investigation.

Examples

Here are some flavours of this anti-pattern:

• String as keys in a Map: I have seen calls to toString() on objects just to use their String representation as a key in a Map: map.put(myPerson.toString(), “someValue”).
• String as enum (“In Progress” , “Done”, “Error”), with tests using equal() to trigger the corresponding logic.
• Array or Collection of String to mimic a data structure, in which case the ordering matters: {”firstname”, “lastname”}.
• String with a special format that makes it parsable: “value1_value2″, but used all over the place as is, with parsing code all over the place.
• String in XML format used everywhere as is, rather than a corresponding tree of objects (a DOM); again there is a lot of parsing everywhere.

The problem

Why not use “real” Java objects instead of Strings? Value Objects would be much easier to use, and would be more efficient in many cases, whereas String obsession comes with serious troubles:

• Repeated parsing is CPU-intensive and allocates a lot of new objects each time
• The code to parse and interpret a String must be spread all over the code base, leading to clutter and plenty of quasi-duplication
• When used to represent meaningful domain concepts, Strings have no method dedicated to the business. The domain operations must be managed elsewhere and selected with conditionals; on the contrary, using value objects makes your life easier everytime you use them.
• String values also need to be parsed to be validated. String values do not catch potential issues early, they will only be discovered when really used; on the other hand, value objects can be validated and can catch issues as soon as they are constructed

Solution

Use Value Objects, that are immutable, with efficient and safe equals() and hashcode(), the convenient toString() and every useful member method that can make them easy to use and. On inputs, convert the incoming format (e.g. String) into the corresponding full-featured object as soon as possible, and use the object as much as possible. In practice the objects can be used everywhere, everytime, as long as they remain within the same VM.

Why the String obsession?

Sure, there are some reasons why some people favour Strings rather than creating additional objects:

• String are already available in i/o, hence you may consider it is memory efficient to just keep them
• String are immutable, behave well as keys, and are easy to inspect in debug
• You may assume that i/o represent the majority of cases in the application
• You may consider that creating additional value objects mean more code therefore more effort and more maintenance

I strongly believe all these reasons are short-sighted, if not wrong. The burden of having to interpret the business meaning of a String each time is definitely a loss compared to creating a object with a meaning as soon as possible in i/o and use the object and its methods thereafter. Even for persistence and on-screen display, having an object with methods and accessors make our life easier than just using Strings!

Business Domains

From scratch, coding this domain can be quite fast, and we can play with the fully unit-tested domain layer quickly. However if we want to ship, we will have to spend several times more effort because of all the extra cross-cutting concerns we must deal with: persistence, user preferences, transactions, concurrency and logging (see non-functional requirements). They are not part of the domain, but developers often spend a large amount of their time on them, and by the way, middleware and Java EE almost exclusively focus on these concerns through JPA, JTA, JMX and many others.

On first approximation, our application is made of a domain and of several cross-cutting concerns. However, when it is time to implement the cross-cutting concerns, they each become the core domain -a technical one- of another dedicated project in its own right. These technical projects are managed by someone else, somewhere not in your team, and you would usually use these specific technical projects to address your cross-cutting concerns, rather than doing it yourself from scratch with code.

Technical Domains

For example, persistence is precisely the core domain of an ORM like Hibernate. The Ubiquitous Language for such project would talk about Data Mapper, Caching, Fetching Strategy (Lazy Load etc.), Inheritance Mapping (Single Table Inheritance, Class Table Inheritance, Concrete Table Inheritance) etc. These kinds of projects also deal with their own cross-cutting concerns such as logging and administration, among others.

Logging is the core domain of Log4j, and it must itself deal with cross-cutting concerns such as configuration.

In this perspective, the cross-cutting concerns of a project are the core domains of other satellite projects, which focus on technical domains.

Hence we see that the very idea of core domain Vs. cross-cutting concerns is essentially relative to the project considered.

Note, for the sake of it, that there may even be cycles between the core domains and the required cross-cutting concerns of several projects. For example there is a cycle between a (hypothetical) project Conf4J that focuses on configuration (its core domain) and that requires logging (as a cross-cutting concern), and another project Log4J that focuses on logging (its core domain) and that requires configuration (as a cross-cutting concern).

Conclusion

There is no clear and definite answer as to whether a concept is part of the domain or whether it is just a cross-cutting concern: it depends on the purpose of the project. There is almost always a project which domain addresses the cross-cutting concern of another.

For projects that target end-users, we usually tend to reuse the code that deals with cross-cutting concerns through middleware and APIs, in order to focus on the usually business-oriented domain, the one that our users care about. But when our end-users are developers, the domain may well be technical.

Every single step matters

Examples of small design-level details that I care about because I have experienced great payback from them:

1. Using Value Objects rather than naked primitives
2. One argument instead of two in a method,
3. Well-thought names for every programming element
4. Favour side-effect free methods and immutability as much as possible
5. Keeping the behaviour close to the related data
6. Investing enough time to deeply distillate each concept of the domain, even the most simple ones

Ivan Moore has an excellent series of blog entries on this approach: programming in the small.

All these details emphasize that code is written once then used many times. The extra care at time of writing pays back at time of using, each time, again and again. Each enhancement that minimises brain effort at time of use is welcome, because software design is a matter of economy.

Other kinds of “details” that I care about involve the human aspects of crafting software: being on site, face-to-face communication rather than electronic media, respect and consideration at all times, always celebrate achievements, etc. Because ultimately, it also boils down to people that feel like building something together.