Tag Archives: DDD

Top Down SOA: Aligning Business Functions

Posted on by

Yesterday I had a really fun time running a workshop at the IQPC SOA conference on Structuring your SOA Project.  It was interesting to see that SOA is still not clearly understood and that the “silver bullet” answers are a still being sought after by a few.
The heart of my workshop centered on the theme that you cannot steer clear of business or domain knowledge, even if you try to design your services by wrapping existing software assets.  It just has to align to reality in the business, otherwise you will just create another architecture that has a fractured line to the business needs.

The other interesting theme that arose, unintentionally, was that it may well be easier to sneak in SOA by thinking in services and building some solutions covertly.  Once value is delivered and becomes noticeable, then start spreading out to the next cell … almost virally.

I summarised the main thoughts in the article on DZone at http://architects.dzone.com/articles/top-down-soa-aligning-business.

Are your modules really modules?

Posted on by

I’ve been struggling with the problem of modules for almost my entire working life. And I am convinced that this area of architecture is one of the most underrated challenges. By definition, a module is a set of parts that can be used to construct a more complex structure. Let’s work backwards. Given a complete design or architecture for a problem domain, we should be able to break into parts and then reassemble these parts to reconstitute the original architecture. We, most probably, can justify any form of decomposition strategy, be it functional, sub-system boundaries, sources and sinks of data, etc. Working forwards is a lot more difficult. Creating parts from nothing that can then be assembled into a complex structure is not easy because we often don’t know what the final structure will look like. This exercise is complicated further when working in an agile manner, where a big design up front is against the grain of short, sharp iterations of analysis, design, test, code, release.

Now think back to the start of a new project, those days where you first tackled a new problem domain. Those days are spent analyzing the domain. And if it was complex domain, you most likely started fragmenting it so that it was conceptually possible to understand little parts at a time. Eventually, you reach a single point where everything clicks into place. That’s your light-bulb moment. It’s an immensely satisfying moment that is filled with a great sense of achievement. And with this fulfilling sense of accomplishment, you naturally carry that conceptual decomposition into the design exercises.

In this very act lurks the conflict. Our modular decompositions created for conceptual understanding is often carried, unconsciously, into architectural designs. In my experience, it is very seldom that the conceptual parts are left alone for conceptual understanding of the problem domain and that a separate effort is expended to focus on modular decomposition for architectural soundness. This resonates back to the days when a huge database design was created early in the project and it was the most static design artifact of the solution. Anything that came afterwards, was morphed to fit in with uber-database design.

I think that the reason for trying to maintain that static set of modules (or that database-design-cast-in-stone) is that refactoring of modules is very immature. At best, it is downright painful because it often results in pruning your source tree. Domain Driven Design is very explicit about modules. There are modules of varying granularity. Tiny modules made up of aggregates or an aggregate and its repository. Big, fat modules based on bounded contexts. Medium sized modules that cohesively fit together because they tell a story in the domain. This is great, but refactoring modules as you discover more of the domain is still frightening. But I digress and will elaborate on module refactoring in another post.

I do view modules as parts that can be assembled to construct the complex whole. But I also view modules as part of a graph, kind of. Every module has a meaningful domain relationship to another module. Each module needs another module to fulfill some feature that is required of the complex structure. It is rare for a module to be completely disassociated from every other module. If a module is disassociated, then is it part of the whole? Hence, the module graph perspective. The graph of modules is likely to be significantly different to the modules that are the result of conceptual decomposition during analysis. This graph of modules is a design exercise, not an analysis exercise. By focusing on domain correctness and meaningful relationships that are true within the problem domain, we can still achieve sound architectural principles. Each module has a public interface and shields internal complexity from its neighbors. This gives us low coupling and good separation of concerns that reflect the reality within the problem domain.

I also believe that using a domain driven design approach that focuses on reflecting reality, will allow for less painful experiences in refactoring modules because the domain must change significantly to force changes to the natural interconnection of its parts. Sure enough, when a business changes strategy, its domain changes which will result in significant changes to modules. But that’s an exception.

So, ask yourself these questions:

  • Are my modules artifacts of conceptual decomposition during analysis?
  • Can I combine my modules to reconstruct the complete complex structure?
  • Do my modules reflect the realities and deep truths of the problem domain?
  • Are my modules, modules?

Subtleties of Ubiquitous Language

Posted on by

There is a thought that has been floating in my mind like an infectious song over the last few weeks and it is Niclas Nilsson’s fault! He posed the question “AOP- Why don’t people get it?” The essence of AOP is the application of old fashioned patterns, mixins and interceptors, using, most commonly, run-time sub-classing techniques. Also, important is that the mixins and interceptors (i.e. the aspects) can be weaved into any object, immaterial of it’s type, place in a class hierarchy, etc. The fact that this happens at run-time in a non-linear fashion (sort of) creates this air of magic around AOP. Not to mention that AOP has some really weird terminology to describe previously well understood concepts.

Andrea Provaglio also participated in the discussion and made the observation that a style class in CSS is, perhaps, an aspect because it alters the appearance of the HTML element to which the CSS style is applied at run-time. Again, I think that if CSS was explained in the language of AOP, it would probably have taken a longer time to gain wide-spread acceptance. What CSS succeeded in doing was to apply a language set consistently, introducing new terms that could be explained using existing, easily understood terms. Even though certain terms (e.g. class) have different meanings when used in the CSS domain, these terms have a foundation in clearly understood concepts.

From a DDD perspective, the use of ubiquitous language is very apparent and thorough in the domain of AOP (i.e point cuts, join points, introductions, advices, etc.). However, I think that the bridge between the language set in the AOP domain and language set of the patterns domain and object orientation domain, from which AOP is derived, is missing. Let me clarify my point with another question: “Would AOP have gained greater acceptance and understanding if it adopted a ubiquitous language set that transitioned already understood concepts (interceptor, mixin, subclassing, etc.) to introduce the newer terms (point cut, join point, advice, etc.)?”

There are three DDD subtleties lurking here:

  1. Having a ubiquitous language is not enough; the language set must be easily understood and explain new terms using already understood terms. It’s like mathematics. We prove new theorems based on fundamental laws and the already proven theorems. Because we have confidence and faith in the fundamental laws and proven theorems, we gain confidence in the correctness of the new theorem. This results in the acceptance of the new theorem. Similarly, explaining new concepts in a problem domain using already understood and accepted concepts increases overall understanding.
  2. The ubiquitous language must aim for simplicity and high readability. If complex concepts are explained in a simple language that is highly readable, it is more likely that the concepts stand a better chance of being understood. Overall, our design and solution for the problem domain will stand a greater chance of acceptance from all stakeholders.
  3. As we explore and gain further understanding of the domain, our language set will change to introduce new terms, bridges between old and new terms, transitions from retired terms to superceded terms, deprecated terms, etc. This occurs during conversation and natural dialog in an attempt to gain further understanding of the domain. But we need to be aware of these changes. What we are actually doing is refactoring our ubiquitous language set. In DDD, the language of the domain is reflected in code. If we refactor our code, we are refactoring our language set. If we refactor our language set, we are refactoring our code.

DDD – Just Entities and Repositories?

Posted on by

Earlier this year Jimmy Nilsson of factor10 presented a great talk entitled “Domain Driven Design – Is it more than just Entities and Repositories?” at PBT Group in Cape Town.  I certainly agree with Jimmy: it is more than just entities and repositories.  While the entity, value object, repository, factory and other patterns are commonly sprinkled in a rich domain model, the subtleties of DDD such as bounded contexts in strategic design are easily forgotten.

A recent article on infoq.com raised the question Can DDD be adequately implemented with DI and AOP?  The arguments are valid in that infrastructure code can be best isolated from a rich domain model using AOP and DI.  This is not at all different to Mats Helander’s earlier article on Looking after your domain model.

However, I cannot help the aching feeling that a large part of DDD is being lost with an often blinkered focus on the lifecycle patterns (repositories, aggregates, factories, etc.) and structural patterns (entities, value objects, services, etc.).  For example, I am currently focusing a lot of energy with Tania van Niekerk (a work colleague) on the issue of designing for modularity.  Modularity is deceptively complex and DDD’s strategic design (bounded contexts, anti-corruption layers, transformations, etc) is certainly helping in us finding a solution.

My take:  I agree that AOP and DI do contribute in keeping infrastructure out of a domain model but, more importantly, I agree with Jimmy that there is a lot more to DDD than entities and repositories.

Reflections on the JCSE Agile and Architecture Talk

Posted on by

It was really good to be part of a very topical subject at the JCSE Architecture Forum last night.  While these discussion are so valuable, the things that surface can only be glossed over, largely because of time constraints.  I end up feeling a very satisfied and energised but a part of me feels a bit hollow.
So here are some of the things that surfaced at the Forum, and my narrow, unworldly opinion on each (i.e. I’m just trying to fill that hollow feeling).

When we talk about architecture, we need to define what we mean by architecture?

In my talk it was a very simple view of architecture which, thinking back, I should have disclosed very early.  I am now applying from Kent Beck who talks about mutually beneficial relationships.   So I think of architecture as the mutually beneficial relationship between two or more things.  So what is a thing?  It could be  lines code in a method, methods in a class, classes in namespace, namespaces in code base, binaries in an application server, application servers in a cluster, … see where I am going?  Architecture is about creating beneficial relationships, and the 5 things I discussed are based on this view.  If you don’t know anything about the things, then you cannot create beneficial relationships.  From an agile perspective, the beneficial relationship that you create should only be beneficial based on your knowledge right now.  Tomorrow your knowledge changes, so the relationship may not be as beneficial as yesterday.  Time to change.

Building infrastructural architecture independently of functional requirements…

I am not convinced of the benefit of this approach.  In my limited experience, every business need defines the constraints or needs of the infrastructural architecture.  I find it hard to find the point of departure, yet there is a school of thought that suggests that function is orthogonal to the architecture.  Perhaps I just don’t understand this.  However from an agile perspective, I want to release early and there are many constraints on infrastructure from the business (for example, administrative processes like procurement of hardware).  I like to understand what these are early on, reach agreement on what we can release at the earliest and design accordingly.  Perhaps the first release is on lightweight infrastructure and that means we “limit” scalability.  So, I don’t design for beyond what I know is real.

Model Driven Architecture …

My view is more philosophical and abstract.  What is a model?  For me, a model is something intangible.  It is a way we understand something.  But we represent our models in many ways.  Through words in written or spoken conversation, in unstructured pictures, in structured notation like UML, even code is a representation of a model.

What do we mean by driven? I view it as a something that takes an input that produces an output.  In this case, we take an input, the model, and produce an output, an architecture.  So, I take an understanding of problem and use that to derive an architecture.  So, that’s nothing new here.  However, I don’t like to confuse driving out an architecture from a representation of the model.  That’s different.  Now we are going beyond thought processes  into mechanical processes.  Then the challenge is about how to apply the feedback to the representation of the model – and that is what will make you agile.  Too much for my small brain.

Plumbing …

Yup, we do too much hand crafted plumbing!  It’s something that we have been working on for a long, long time.  I think convention over configuration, dependency inversion, meta-programming are all attempts at addressing this problem.  Some early success that I have experienced is on taking a polyglot approach. I am not talking about mixing general purpose languages on one runtime only.  I am also including domain specific languages. I’ve had some early success where using DSL to describe functional intentions and then generating a large portion of the plumbing.  Where I’ve suffered is when I mix concepts from different domains.  There is the domain of plumbing and the domain of the business.  Whenever I’ve mixed the two, it pains later rather than sooner.  Right now, the only way I’ve had some success is with aspect orientation and meta-programming.

@StatelessSessionBean …

Chris Naidoo is right.  That thing called J2EE and subsequent versions is just horribly broken.  It’s broken encapsulation and a whole lot more.  The fact that we now must use an annotation and not implement an interface is immaterial.  Both result in the same pain – mixed concepts (see plumbing above).  Annotations should be specific to the business such as @RecalculateCostsOnRerouteOfCargo can be used as an interception point for injecting a rule on a class or method.

I would go even further and say that the POJO JavaBean specification is also broken.  Why on earth must I have a no-argument constructor and accessors and mutators.

Last thoughts …

I may have missed some of the other discussions but these are the ones that I woke up with this morning. In general, my observation is that we need to be very concrete very early if we want to be agile, even in architecture.

Trust Everything

Posted on by

Trust has popped up in so many of my conversations recently.  It came up at home, at a new school that Lia will be starting next term, in the DDD course that I gave earlier in the month, in Peter Hundermark’s scrum master certification course.  And I got a one line email that said this.

The entire world lives on trust. Every aspect in life moves with trust.

The more I think about situations in life that will prove this statement false, the more it seems to hold true.  Even in design it holds true.  Your most fundamental architectural decisions are based on trust and the implementations of that architecture work because of trust.

It’s true for code too.  If you don’t trust the code on which you build or depend, then you might as well write everything yourself, and give up your place on your team.

I was thinking about the AOP with DDD tutorial that I will be giving at OOPSLA this year, and this trust thing came up.  Here again, aspects and the classes into which they get woven, need a trust relationship.  It may seem like a stretch to make that statement, but I think it holds true again.

So, how do you gain trust?  I am not sure, but I think you have give up something first.  Maybe you need to show your vulnerability first, then it becomes easier to let someone into your space.  Then, perhaps, they will let you in to their space too.  When ego walls are erected, then trust finds it hard to grow.  By ego, I don’t mean arrogance, I mean awareness of your self that you hide from others for fear.  Perhaps, it is only when you show your true interface, that the other will worry less about hidden agendas.

In code, trust lies in interfaces and types, not in implementations.  It’s really about trusting the implementation that makes types worthy.  When you trust the type and send it a message and it behaves as expected, then you trust it.  If you request something of an abstract type and the message was received by an instance of a subclass, then you expect the subclass to behave like the abstract type.  You don’t hope that it does behave consistently, you trust that it does!

Trust is tied in with ubuntu too.  You can’t be part of a community nor allow yourself to be defined and shaped by the people around you, if you can’t trust them.  I think ubuntu coding needs trust as one of it’s values.  It’s already a value in XP, and Scrum, and families.  It needs to be in teams, and organisations, and communities and nations too.

Intention Revealing Names

Posted on by

Update: A small elaboration of this has been published on the Architects zone at DZone.com.  Read it at http://architects.dzone.com/news/intention-revealing-designs.
The value of naming of variables, methods and classes is highly underestimated. Given that code is read more than it is ever written, the readability of your code will get more attention than your original thought process that led you to the code. I will be so bold as to say that the reader really does not care how you arrived at those lines of code. The reader is actually focused on what you mean by the code and not how it does its magic.

Often the problem lies in carrying implementation details into the name of the intention. For example, assume you have designed a social network as a directed graph and you want to find all circles of friends that are in this social network (e.g. Joe knows Mary who knows Peter who knows Joe). Since it’s a graph, we can find all cycles in the graph, or closed loops. So, you write code such as:

class ObjectGraph {
  public Collection<CyclicGraph> findCyclicSubgraph() {
	  ...
  }
}

class CyclicGraph extends ObjectGraph {
  ...
}

This does not reveal any intention of finding circles of friends nor does it surface the domain adequately. The same code with intention revealing names just reads better:

class SocialNetwork {
	public Collection<SocialNetwork> findCirclesOfFriends() {
	  ...
	}
}

There’s a subtlety hidden in the refactored code. Both the circle of friends graph and the graph of the entire network are of the same type. SocialNetwork is a composite and has the advantage that all operations executed on a composite will yield a composite of the same type as well. In other words, all operations on SocialNetwork will yield another SocialNetwork. That is also intention revealing design as well as a bit of suppleness.

Here’s another example. You wish to set a boolean to indicate that an object is dirty in your cache.

public void setDirtyFlag(boolean dirtyFlag) {
	this.dirtyFlag = dirtyFlag;
}

But refactored with intention revealing names, the purpose is now explicit.

public void dirty() {
	this.dirtyFlag = true;
}

public void clean() {
	this.dirtyFlag = false;
}

Whenever you are writing code, ask yourself: “Is my intention clear and unambiguous?” If the answer is “No!” then your code is most probably lacking readability. There are refactoring techniques and many patterns that can be used to increase the suppleness of your design, but just spending a few extra brain cycles on the names that you use in your code can make an enormous difference in displaying your intention and not your implementation. This alone will increase readability and reduce maintenance of your code.

Launching the Services Support Group

Posted on by

“Hello.  My name is Hope and I am a Service.  Last week I was asked by a View to do something.  I told the View that I can’t do it.  So he asked the Fat Controller.  The Controller sent me the same message and I just took exception.  What kind of service does he think I am?”

“Hello Hope.  We are glad you joined us.  You are not alone.  Look around the room.  We’re all struggling to find our own identity.  Those of us that have been around for a long time are still recovering from being forced to convert DomainObjects to DTOs.  The more recent ones feel like meaningless proxies, and last week we had a guy who thought he was a Service but he was just a HelperClass.”

“It’s as if I am losing touch with reality.  My own DomainObjects don’t even interact with me directly.  Now processes want a piece of me too.  I think I am schizophrenic.  Am I now a process?  A wrapper point for Transactions?  I swear to you, there are days when I even think I am a stored procedure!”

“Ohhhh, noooo!”

“But I know who I am. I am a Service.  I like working with DomainObjects.  They need me.  Somethimes they can’t do everything on their own, so I help out.  I complete their world and it makes me feel like I belong in the right place.  One guy even refactored me from the domain package to a services package.  Can you believe that!  Actually, now that I’ve said it aloud, I am not surprised that I feel more and more disoriented.”

“Disoriented?  Oh boy, we really can’t help you here.  You see we’re recovering from abusive Controllers and Views and when you told us the story in the beginning, we thought we could help you but you’re just a …”

“But that story is true.  Apparently there was this Process on other side of  this MessageBus that needed something and he asked the Fat Controller who got involved with View and then I got sent this message and …”

“WTF?!!  The Process asked the Controller…”

“Yeah!  You won’t understand … it’s after your time.  It’s really a WebServices Controller but I hear that he also feels abused and just wants some REST.  You think there’s a support group for Controllers?”

“Wait.  I remember this other crowd … uhhmmmm … sorry – those weren’t Controllers, those were Presenters working with Models and Views, but I used to be confused as a Delegator and I can …”

“You’re NOT HELPING!!!  I told you I am a Service!  And I am confused!  I want to be part of the domain again!  I feel disoriented!  And I …”

“And I told you that we can’t help you.  The truth is that you are DOA.”

“Dead on Arrival?”

“No! DisOriented Architecture.  You know … they don’t know where to put that, so it becomes a service.”

“But, but … I am a Service … <sniff>”

“YOU WERE NEVER A SERVICE!  YOU’RE ONLY HOPE!!!”