I’m currently working on a project where the long ago choice to use SOAP as standard for all our services is making people stop thinking. I’m convincing that reconsidering technical choice when a valid and valuable context arises is an attitude that should be natural for all architects. But in the reality, it is not… Or maybe they might not be architects.
I’m the kind of guy who prefer understand the “why” instead of learning the “what to do”. I’m an architect and by definition I think ahead, and I design a minimum up front. If I found something illogical…Well I will challenge it.
Let me be more explicit on this. I need to build some services for a mobile middle ware. Those services are DATA services. They only provide CRUD operation on some entities that will made available to a mobile client. This mobile middle ware supports 4 kind of communication technologies (SOAP,SAP RFC, REST, SQL). It supports them in the same extend. Meaning it will not be able to support the full extent of features (transaction, security, reliability…) that each of those technologies support. It supports the bare minimum.
Because we want to be SOA……. (Yeah!!!!) We have to use SOAP…(Yeah… What a shortcut…). Fine we are building DATA Services, and we need to use the more complex protocol for our services… This is a non-sense. Those services are meant only for this middle ware. Their contracts are tailored for the middle ware. There is no possibility for them to be used by something else than the middle ware and we are choosing the most complex and universal protocol….
Why not considering something simpler like REST and a simple and optimized XML message? “Because this is not a company standard!”… What can I reply to this? I believe that this choice can make sense (Yes I say can make sense J) when the services you are building is meant to be a companywide service and used by different platform. But then it needs to be advertised like this. This is not our case… We are mainly providing services that list all instances of some entities. Those services will return hundreds of thousands of records. Let’s reconsider that companywide standard for this case and use it properly. Let’s build something which our customer will take advantage of for once. Let’s be “Thinker” and not follower this time.
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.