Structural Domain entities or Context oriented Domain entities

I’m working on a project that has been going on for couple of years now. We manage to deliver a solid and nice application composed of several building blocks. Those blocks  go from front end web application to mobile disconnected application all serviced by Web services components.

This web service components are build on top of a DDD Architecture. The challenges we are facing now is that our Domain entities were design based on a structural approach and our domain entities becomes quite complex. For example we have a project aggregate root made of work package entities and them self made of activity entities.

At the begining of project we had only a limited kind of project and activity type. The scope of the solution is constantly increasing and we are now having far more type of project and activities. Those domain entities become bigger and we have a lot behaviour which are partially overlapping each other and it is hard now to change one type specific behaviour without impacting the other inherited.

In my quest to make all those complex entities more manageable and less interdependent. I’m trying to restructure them in bounded context and to organize them in context oriented entities. Meaning I’m trying to build entities which are meant to support some dedicated context and processes. Instead of having a domain entity model that looks like my database model. Their are now behavioural oriented not structural oriented.

By doing this I’m ending up with far more aggregate roots but which are simplier and more maintainable. The repository are also now more complex as well. Before we had almost a one to one relation between a domain entity and the database model. It is not the case any more. We may end up by reading five different table to build a simple domain entity. I can live with that after all this is what the repository is there for. Serialiaze and deserialiez my domain entities.

The major issue i still have to face now is the resistance of the development team to work this way. They have the feeling that we will end up by duplicating a lot of business rules. I tried to show them and explain them that if a business rules needs to be duplicated they we might have to refactor the bounded context cause they might not be that bounded… But that did not do the trick 😦

Has anyone gone throug the same experience? I would appreciate any advice on this.



SOA Patterns: Entity Linking

Amongst the recently 5 new SOA patterns that were promoted from the candidate list to the Master list of  the Master SOA Design Pattern Catalog, there is one pattern that I found pretty interesting. It is the Entity Linking.

The idea behind this pattern is that, if you have defined several entity services in your SOA landscape, you could provide with one of the entities the id of the references entities AND the links to get access to those referenced entities. To be more concrete you could have two services, the order entity services and the product entity service, and when requesting an order entity you will get with the order entity the links to all product entities which are referenced in the order.

This sounds interesting but can it be implemented? Are there any person who have tried to implement this pattern? I’m curious about the technic they have used to manage their links. I will be investigating more on this and I will keep you informed on my findings.

Why an entity key should not be a technical id.

Like most of application architect out there that I have meet, I used to add a primary key column to every table I added to the ER Model I was working on. It was like a reflex: I create a customer table then I add a column “Pkid” of type int. The values of that column will be given by the RDBMS.

That column had no meaning but the one of giving me a unique value for the table record. That table record was then linked one to one to my business entity. It was fine by that time. But… Then came distributed and loosely coupled systems. The instance of that entity may not be created centrally anymore. It may be created on a disconnected device and referenced by another disconnected instance. This is becoming more difficult to handle.

It is not impossible but more complex. The disconnected system will have to provide a temporary key and used it as the FK value by the referencing entity. Then after posting the entity to the entity owner systems, it will have to update those temporary key with the final values provided by this owner system…. Fine!!! It works… But… My central system may have been sized to support a well defined number of users and the processing of those entities creation request may be pooled… Meaning I do not get the finale Id right after the posting and I may get entities that were created on other disconnected systems. Those new ones may have used as Id the same value that I used… Oups… Trouble again…

Well you may go further and find a good solution for it but at what cost… My advice is to not use a RDBMS primary column as your entity key. You could do it on the RDBMS but this key should not be used outside your RDBMS. You should have a candidate key for which every external system is capable of creating new and unique key. Ideally a real business key or if that is not possible, a Unique identifier like a Guid.

This will save you a major headache when you will go from that centrally managed system to a distributed and lossely coupled system. Trust me.

Prefixing interface with I

I’m currently reading the book “Clean Code A Handbook of Agile Software Craftsmanship” From Robert C. Martin and I read something that I would like to comment. In the section “Avoid Encoding” he mention the prefixing with an “I” the interface that should be avoided. Instead we should use, if needed, a suffix “imp” for the implementation class.

This is a convention which is quite used in the Java world. I’ve downloaded a couple of open source framework in Java just to read their code source and I’ve found that convention used on a lot of them and I do not like it much. I prefer to use the I on the interface. Why? Cause the only unique element in an interface and the class implementing it, is the interface. Imagine the example provided in the book.It gives ShopFactory for the interface and ShopFactoryImp for the implementation but what about another factory implementing the interface. a Mock for example. It will be called ShopFactoryMockImp? What if they implement multiple interface?… I don’t think so. We should call the interface IShopFactory and all the class implementing it may not have to reference the interface name in their names. This is cleaner and makes more sense.

The real question is should we use any prefix on the interface? And again… I believe so. Why When I’m browsing the solution files I like to see in the names what are the interfaces and what are the classes. Same thing when looking at the code, I like to know what is the base class and what are the interfaces amongst the inherited base class if any and the implemented interfaces.

I hope this comment will help you make your own opinion.