Archive

Posts Tagged ‘design’

Event driven architecture should be a must go (esp. for client side JavaScript)!

While reading Getting Started with Twitter Flight, I realized that only events provided an effective decoupling between data producers and consumers. Not Object Oriented Programming. Not services. Sounds crazy? Sounds wrong? Read on and let me know.

At first, with events, some benefits immediately pop up:
– internal changes have not effect on external code. None at all. No renaming or bigger change affect the other components, even the ones depending on this component (as long as the event itself is untouched).
– willing to change the event? Just have a look to who depends on it. No need to try to track use of some service/object/whatnot all the way through your application. And in JavaScript, doing so would be especially bad: no type, no compiler. Only plain text search through methods name (at best). Good luck with that. And if others depend on your code, well, they’re basically screwed. With events, it’s way simpler to do changes. Even deciding to version public events could be easy.

But, actually, events provide way more: they decouple events producers from listeners. Sounds trivial, for sure, but going deeper it means no need to inject some service, register somehow somewhere for callbacks, no need to look at an object with plenty of methods/stuff in it. The API to communicate with others parts of the software is actually uniform! You won’t have a specific way of doing it for each need. You just want the payload, no need to read some non existing documentation to figure out to use the crap.

The mental noise is tremendously reduced. You need to signal something to others? Easy, fire an event. You want to know of something? Easy, listen to the event. That’s true decoupling, way more that some abstract FooService with plenty of methods, related objects and extra funky behaviors or dependencies. Just the stuff you need, always through the same mechanism.

What does it mean in practice?

Well, very nice stuff:
– willing to test something when receiving an event? Plain simple, just fire it! No need to mock or whatnot the sender.
– needing to add 10 new ways of firing the same event in the UI? Plain simple, you just fire the event in the new places and all the listeners will get them. No need to change the listeners!
– you need to kill some component and fire the same event in a different way? Fear not, delete without looking anywhere else and produce the same event wherever you need it.
– you rely on some external component that you want to swap for something better. For sure, since you’re on the UI side, you didn’t code defensively. So you’ve plenty of reference to the old component’s events. Screwed? Not at all, write a component translating the events from the new format to the old one and… done!

Such ease of coding is something I would love to have whatever the language, be it Java, Scala and even more JavaScript, which has way less tooling for code exploration and refactoring.

It made me realized a funny point: Object Oriented Programming (OOP) came with the concepts of objects to encapsulate logic and data, and (public) methods to communicate with others objects. Actually, in the beginning of OOP, methods where sometimes called messages. It’s still used and visible in Ruby nowadays. Theses messages were supposed to help decoupling. The internals would be nicely hidden from the others, only the stuff needed by the outside would be visible.

Yet, in fact, you can’t get the message/public method without the object. And the object doesn’t come for free. You need to get an hand on it, to figure out what it intends you to do and so forth. The decoupling aspect of methods is pretty bad in the end. Whereas for events, it’s all bright and sunny 😉 You can get the message without the object mess. Crazily good no ? And you can change the internal, even drastically (aka delete), without affecting the outside at all.

It sounds like the Single responsibility principle done right isn’t it? Damned, I tried for so long to do that in plain old OOP…

Anyway, thanks a lot Tom, the author of Getting Started with Twitter Flight, for having made me realize this point so clearly.

All is not rosy though for sure. Infrastructure code, utilities, libraries and the like may still be used in many different parts of the same application. However, this kind of code is generally pretty focused, trying to do one thing well, and has few, if any, state. As such it’s easily testable and refactoring is seldom needed. Should the need arise, it’s generally pretty strait forward. Domain related code is a completely different story: state is everywhere, refactoring frequent. So an event driven architecture, if only for domain and application level code, already provides plenty. And is, IMHO, way better than all the alternatives I know of as of now.

Étiquettes : , , ,

Book review: Growing Object-Oriented Software, Guided by Tests

mars 17, 2014 1 commentaire

Not being fully satisfied about my TDD practices, I was reading The Failures of « Intro to TDD », which sums up nicely bits of the uneasiness I’m facing and offers a nice way of handling it. While tweeting about the article, I was once more told to read Growing Object-Oriented Software, Guided by Tests, and so I finally did and here is my feedback on it 🙂

Lire la suite…

Étiquettes : , , , ,

Book Review : Implementing Domain-Driven Design

février 11, 2014 Laisser un commentaire

I had a bit of free time recently (I guess finishing the 15 books of Games of thrones I was given did help as well lol), so I could tackle some books resting on my shelves. Among them, Implementing Domain-Driven Design, by Vaughn Vernon.

Well, first of all, contrary to Mobile First Bootstrap (cf previous review), Implementing Domain-Driven Design is a massive kind of book: about 600 pages. With plenty of code samples. And actually, that’s were, IMHO, the book is a pain: it goes too much into details. I don’t care too much of Spring xml config. Or some coherence API details. Or some REST based communications between parts of the same application (heck, is it really a good idea anyway ?). My mind is set more on akka, and turns out Vaugh Vernon just as well.

The level of details and the lengthy code samples really killed my attention times and times again. It’s a pity. A first the book starts well, Vaugh Vernon does a great job highlighting the usual pitfalls of non Domain Driven Design. It really rings a bell quite a few times. But then, the technical details get in the way, especially for opinionated coder like me. Supposedly immutable value objects without final fields always hurts me. The extensive use of static methods as well (I just remind one « disclaimer » saying it was for the sake of concision, and pretty late in the book).

That’s why, I think, very detailed and framework related code samples are quite a gamble in a « design level book » : if you don’t care too much about the frameworks and some code hurts your eyes, you tend to forget about the design level stuff.

It wasn’t all bad, for sure. It was nice to go through, again, the ideas contained in Domain-Driven Design: Tackling Complexity in the Heart of Software (I wrote a review on it in 2010, here). Some refreshers were really welcomed.

Another aspect which disappointed me was a feeling of a lack of « hands on » feedbacks, of first hands experiences/insight. When reading Uddi Dahan, for example, there were plenty of times where I thought « yes, that’s the issue, he nailed it ». It almost didn’t happen on Implementing Domain-Driven Design. Maybe the burden of detailing Spring and the others chosen stacks killed the « light revealing » feedbacks, the perls of wisdoms which really help one progress. Maybe, as well, I’m biased there: I’ve read a lot on the matter, played with akka persistence, helped Uwe creating his homegrown CQRS framework (still unpublished by the way, isn’t it mate ?). And I’ve plenty of design/implementation related questions in mind which haven’t found their answers yet, but maybe only walking the path would provide them. Yet, nothing about handling eventually consistency in the user interface in the book for example, despite it being quickly an issue, potentially at least, in event driven systems. What if events change over time, how to handle such changes in the event store ?

So, to sum up, if you’re planning to use Spring and some RESTish stuff, the details could be a real enhancement of the book. Otherwise, like me, I fear they risk to wear you off quickly, killing the interest of the book. Furthermore, if you’re a lot into event driven/CQRS and the like, these parts aren’t handled with too much details, more as an overview, which might disappoint as well.

Well, I feel a bit hard. I hope I’m not unfair and that my disappointment doesn’t make me harsh. If you think so, let me know…

Étiquettes : , , ,

Book: Patterns of Enterprise Application Architecture

I have a hate/love relationship with IT books. Really. On one hand, I love to read them. On the other, when they’re good enough, I feel compelled to blog about them. And it bugs me so much I’ve to do it before being totally free for some other books. As such, let’s speak of Patterns of Enterprise Application Architecture, by Martin Fowler.

As said in the title, the book is all about enterprise patterns and actually does it very well. Indeed, crazily enough, there’s more in IT than just the Gang of Four patterns… Stuff like optimistic (offline) locking, the Active Record pattern, Gateway and way more.

The book is divided in 2 parts: first Martin walks over what he calls « The Narratives ». There the stage is set, and the general issues are introduced for the reader to get a proper overview and understanding. Layering, mapping aspects, transactions isolation levels, ACID implications, session, remoting… All these concepts are nicely put together.

Then each pattern is seen in details: how it works, when to use it and some examples (mostly in Java, but C# and maybe some others are also covered). The presentations are well done, presenting pros and cons as well as the various way to implement each of the patterns.

The book shows hardly its age, having been written in 2002. For example, Dependency Injection isn’t spoken of. Similarly, at the time, XML was fancy, so Martin Fowler speaks of it several times, which is funny in retrospective. Still, most of the patterns are still relevant and are important to know, so it doesn’t matter.

In the end, I wish I had read this book (or learned its content) when doing my Computer Science Degree. Indeed, since, I’ve come to know them, but it’s really because I’m interested in the topic. Yet they are of the uttermost importance for anyone in the field. They should be basic knowledge, in order to have a better understanding of the problems at hand, communicate properly between practitioners of the art and not reinventing the wheel .

Furthermore, the extensive coverage of the book should still teach some stuff to most of us.

For example, Kent Beck at some point speaks of remote computing, saying that remote interfaces tend to be coarse grained, whereas local ones are fine grained. Indeed, when going over the network one wants to have as few calls as possible, whereas locally one wants clear intentions and fine control. While obvious, I wasn’t so aware that one interface would be at pain to serve both purposes.

I also loved Martin Fowler First Law of Distributed Object Design: Don’t distribute your objects!

Still, I’m only scratching the surface of this 500+ pages. Martin Fowler was nice enough to provide an online Catalog of Patterns of Enterprise Application Architecture, which should help to get a better view of the book’s content. Since the book publication, a new pattern was also made available online, the Domain Event concept, which is worth looking at.

One more thing: the book is part of the « Martin Fowler Signature Book » series, and thus has a proper hard cover and a nice red bookmark fabric. Cosy and very useful 🙂

To sum up, very nice book to get quite some overview of the general concepts at play in enterprise architecture. Almost a must read actually.

I stop here otherwise I fear I’ll write more than there’s in the book 😉

++

Programming in Scala quote for adiguba ;)

mars 24, 2011 2 commentaires

I thought he might like this bit, so, I’m quoting Neal Gafter foreword to the first edition:
« Since that time, we at Sun tried to simplify program development by extending the language with piecemeal solutions to particular problems, like for-each loop, enum, and autoboxing. Meanwhile, Martin continued his work on more powerful orthogonal language primitives that allow programmers to provide solutions in libraries. »

Nice isn’t it ?

Étiquettes : , , ,

Book: Domain Driven Design

octobre 1, 2010 1 commentaire

When I first started to work, I knew I was doing crap. Yep, really. We were using old stuff, copy/pasting heavily, editing config files by hand before deploying in production and so on. However, knowing you do crap doesn’t help you doing right, even if you had the occasion.

As time went by, however, I was lucky enough to work with real Software Developers, craftsmen as we would say today, learning a lot on the way.

Yet, even these bright guys were sometimes uneasy. Not on technical stuff, not on infrastructure, but, well, you know, on the classes and the like you’ve to do for your customer. How shall we split the different parts of the requirements? What should be top level code or just « code that works », intended not to be touched more afterwards. To which extend shall we integrate what’s the business requires, or shall we adapt it a bit to our stuff ?

Yet, these foggy stuff are the value of an application. Customers don’t care too much about how nice your XML described UI is. Nor does he care too much about maven and the like. He cares about these (often messy) code doing what he asked for. The code which enables dealership to get their good in time. The code which triggers automatically some buy on some mutual funds. The code which allows to display the breaking news. The user’s code. And on top of that, whatever the nice technical layers around, if the users’ domain is badly understood and/or translated into code, then it’ll be a mess and massive pain to work with.

Domain Driven Design is all about this code which actually is, or at least should be, the heart of your application. This « domain » code is where the real value is. Ṫhe book makes the obvious visible again: the domain, the users’ stuff, is what matters. Even better, the books describes plenty of means to handle this part of your application, from quite low lever to high ones. How to handle large domain. How to refactor towards greater insight (a chapter title actually). It even has a chapter called Strategic Design, speaking about how to handle these different domains which always coexist, and how to make the best of them. Most important of all, the books is all about the UBIQUITOUS LANGUAGE.

The uppercase is not mistake: the UBIQUITOUS LANGUAGE is what allows users and developers to understand each other effectively and over time. It matters. The UBIQUITOUS LANGUAGE deserves its uppercase. And by doing so constantly in the book, with the core concepts, Eric Evans makes it obvious what matters or not. After reading the book all these big uppercase words will stick to your mind with ease. ANTI CORRUPTION LAYER. REPOSITORIES. BOUNDED CONTEXT. They’re all still there 🙂

To tell more about the UBIQUITOUS LANGUAGE, it’s the language used to describe the domain, both by the users and the developers. It is should be reflected in the code. And, of the highest importance, is should evolve with the comprehension of the needs. This is the domain. This is the added value of your work. Eric Evans takes care of showing ways to handle this UBIQUITOUS LANGUAGE and make it pervasive and effective. His examples are clearly first hand ones, which smell and look like what you could expect tomorrow (or on Monday rather lol). No big word on SOA or Agile Manifesto. No, just how to make your users needs properly fulfilled. On top of that, the author speaks of organization at the code level and higher ones (like what to do with big blobs of codes or legacy systems). This uncommon « elevation » is very nice and helpful. Speaking of more than the GOF patterns as a way to make your code base intelligible is very nice. In fact, the book’s title second part « Tackling Complexity in the Heart of Software », is true and right to the topic.

I guess you got it, I liked this book. It makes you think and ponder often, on your current practices and on « industry wide » ones. Like the habit of affecting the best developers to the infrastructure teams. Common isn’t it ? These top notch guys can then develop some stack able to solve both desktops and web needs, transparently and recursively. Sounds all good, but is this what your users want ? They want their needs fulfilled, they want their reality to be tackled. And whatever your bells and whistles, if you can’t move stuff Y to point 1243, it’s no help.

Well, I fear I’m too verbose. By the way, the book is quite verbose as well. More than 500 pages and extensive texts. Reading it took quite some time, even if I liked it. It was just big, both in volume of text and on impact of its content. But it didn’t go in the way, apart that at the end I was wondering about stuff explain at the beginning. But then, no big deal: for sure I’ll read it again.

To kind of conclude, this book is the last bit of theory I was missing towards making great software, in the long run, in a sustainable way, for the users. It has already changed the way I approach design and it looks like my users felt and liked it already.

I already said too much: I’m off !

++
joseph

Étiquettes : , , , ,

Thoughts and questions on Pragmatic Unit Testing

septembre 7, 2009 2 commentaires

2 points stroke me when reading this « Pragmatic Unit Testing » book :

– in order to easily test some class, they suggest to open the required methods by making them protected. I had first to check that protected included package readability (it does) but still I think it’s going a bit too far : if the method was supposed to be private, package private is the nearest visibility which would fit. I would only make it protected if I intent to override it. Do I miss something ?

– the last paragraph is called « Testing invalid parameters », and speaks of where to test the validity of the parameters. Their answer is « we find the easiest rule to adopt is the ‘keep the barbarians out at the gate » approach’, meaning internal components can trust the data they get. At work, we do it differently : every non private method has to check for the validity of its input (for which we have a dedicated assertion lib.). Would you suggest otherwise ?

++

Étiquettes : , , ,
%d blogueurs aiment cette page :