Saturday, June 9, 2012

DDD in Sharepoint. Part1– philosophical

I wanted to write a serious of posts about using of DDD in Sharepoint from a long time ago, but because of lacking of time and very tight schedule during last months can do it only now. I used DDD before to start working with Sharepoint – in ASP.Net and win forms applications. Currently I also have wide Sharepoint development and architecture design experience, including using of DDD in large Sharepoint projects. But of course I worked not only with DDD, so I can compare various approaches using my own real-life experience. Hope this reading will be useful and interesting for you.

This material will be useful mostly for developers who is working on medium and large projects, who understands the business-value which brings DDD. If you need quickly develop a web part which displays data from some storage, it will be overengineering most probably. But if your goal is to build solid and maintainable architecture for the system which supposed to be used for years, then it will be helpful. This part of the serious won’t contain any code examples. I will try to answer why and when you should use DDD. In the next parts, I will describe key technical solutions which can be used in practice. Let’s start with brief introduction to DDD and where we should use it and where not.

In Sharepoint you may manipulate data by several ways: you may work with SPListItems, OTB Content by query web part, Data view web part, BCS, external content types, etc. The advantage of this approach is that all of these comes out of the box and you may start using it very fast. But this approach has significant disadvantage: it hides business domain model from developers. SPListItem may represent OrderItem, Product, Checkout transaction and so on, it can represent anything. When you will read code which operates by list items you won’t immediately see what it does in business domain. Also code won’t reflect ubiquitous language: common language for all team members including developers and business people. As result code became less clear, it is harder to understand it, which in turn leads to more bugs and confusions. It will be hard to change it in future. Business rules are not static: in modern world business should be able to change very quickly for versatile market conditions. If your software won’t reflect business needs and won’t be ready for changes, customers will choose another vendor (one of the projects which I worked on, was the project from another vendor. The code was written using approach described in this paragraph. But it caused so many problems, so finally business decision was made and customers changed the vendor).

Another way to work with data is to build clean business model using POCO (or at least generated by automatic tools like in Linq 2 Sql) and build infrastructure for working with them by yourself. With this approach developers will write code in terms of business domain. They will manipulate by Products, Orders, Overdraw limits, etc, etc. – e.g. by terms which are understandable by business people. Yes it requires more work from you on initial phase, because you need to add extra layer on top of raw SPQuery and SPListItemCollection. Instead of using OTB CQWP you will need to create custom web part which uses repository in order to retrieve objects from storage, then convert them into view model (this step is optional) and pass to the view, which will render it for users in appropriate form. This approach follows DDD style. Although in Sharepoint you may need to combine DDD infrastructure with OTB web parts – it will allow you to decrease implementation time which may be crucial for business. This approach also works. You just need to remember that core of your application anyway should be expressed via clear domain model.

Whether you will use DDD or not I highly recommend to read Domain-Driven Design by Eric Evans or at least Domain Driven Design Quickly, if you don’t have time to read Evan’s book. I always recommend it for all developers, regardless of the technology stack or programming languages they use. Yes, I don’t ask members of my Sharepoint team to read books about Sharepoint workflows, search, BCS, web parts and other technical stuff in their free time. In most cases in order to start using them and bring value for business immediately it is enough to have some background and turn on your head (e.g. I get this background by reading blogs of developers – the same developers as I am). It is impossible to know everything, that’s why instead of reading such books, it is better to teach yourself to quickly teach any technology, but it is too philosophical and too far from current article’s subject :). Probably I will write something about it in future.

Of course there is no direct answer where to use 1st approach and where DDD-style approach. You still have to evaluate all pros and cons and make decision by yourself and take this responsibility. As any other paradigm, framework, technology – it should help you, not prevent from making things efficiently. If for supporting of DDD infrastructure you need more time than for implementing actual business tasks, probably you should re-consider it.

Personally I prefer DDD approach for most of my projects: but I work mostly with medium and large projects (starting from 2-3 man years). 4 last projects where we used DDD were successful: they were implemented in time without major problems and within budget (almost :) ). 1 large project which we got from another vendor tried to use DDD but only in one part of the functionality (say 25% of whole functionality): this project was not very successful. The reason is not only in DDD of course (main reason of success is great team and each member’s attitude, because as said Jim McCarthy in his book Software for Your Head: team = product), but from my point of view it was important success factor. I added exact digits here in order to give you ability to reference me when you will argument using of DDD for your chief :). Probably it will add some weight to your scalepan.

Another reason is more psychological: you will make your work better if you enjoy it. I enjoy working with clean model without infrastructural noise, and I use it not only in Sharepoint of course. I use it in ASP.Net MVC, web forms (yes, yes), win forms, python projects. People reading this code said that they really like it and will use it in their own projects (to be honest I heard only one negative response from the apologist of single static class on thousand lines of code. But as he was not from my team I didn’t try to argue with him. I have more useful things to do). From other side when I need to work with code for maintenance from another company where I see SPListItems, TaxonomyFieldValues, SPQuery, etc. applied without business model layer, I fill very uncomfortable. Also it makes me think why customers stopped working with vendor who created this code.

This was brief philosophical introduction to the DDD in Sharepoint. Hope it was not very boring. Promise that next parts will be more practical and will have a lot of code examples.

72 comments:

  1. Thank you for this post. Would be interesting to get some code illustrations of DDD for SharePoint.

    ReplyDelete
  2. Solid maintainable architecture can't be build with DDD, especially in SharePoint. There is no one notable app built with DDD and have maintained for years.

    SharePoint project first of all is a bunch of plugins and OOTB feature configuration. SharePoint provide rich set of features and there are no need to create abstract model. No features can work with you model.

    ReplyDelete
  3. Станислав Выщепан,
    > Solid maintainable architecture can't be build with DDD, especially in SharePoint.

    first of all this is your own opinion. If you didn't have successful experience with DDD in Sharepoint it doesn't mean other didn't too. Second this is not correct even if you won't use any another info, except the article above. As I said we use DDD in medium to large projects - all of them were successful. And I know that for most of people who used to work with "classical" approach (1st approach in the article) won't understand the value which DDD brings to the business.

    I'm not young fanatic who read another silver bullet book and want to use approach described in it everywhere now. I write in using my own real experience which shows that DDD improves quality of Sharepoint projects. That's why I didn't want to write it until will have enough real projects built with DDD. As an architect and team lead I'm interested in result for business first of all. Whatever architectural style would used, if customers are happy I'm happy. Experience shows me that when we use DDD customers are happy more often than without it. Also as practice shows developers are happy with it too.

    > There is no one notable app built with DDD and have maintained for years.

    change or die.
    (but seriously I didn't want to comment this, because even if it would be true (which is not I believe. However I don't have proofs and don't have time/wish to search them), it won't change my experience).

    > SharePoint project first of all is a bunch of plugins and OOTB feature configuration. SharePoint provide rich set of features and there are no need to create abstract model.

    "SharePoint project first of all is a bunch of plugins" - here we have different points of view. For me Sharepoint project is not "bunch of plugins", it is serious projects which have explicit business model which have to be expressed in the code. If you treat projects as "bunch of plugins" and, what is more important, if you like to work like this, this article is not for you. You may continue to work as you used to (and it is Ok actually. Money in Sharepoint development world is not bad and if you can configure BCS and show it to the customers, they will most probably happy and treat you as a guru - until the first customization which have to be done in it). But again - in my case I talk about medium to large projects, which in most cases have custom database and which can't be done by just manipulating mouse. DDD is not needed everywhere.

    It is very true that there are many OTB features which you have to use. I said the same. In Sharepoint you have to combine DDD with OTB features in order to keep development costs on competitive level. It is not possible (and no need for that actually) to built pure DDD architecture in Sharepoint. E.g. if your data is stored in the lists you of course don't need to customize list forms in order to use repositories for saving data into the list (it is even sounds silly). But in order to show it or use in some calculations you may use repositories and work with POCO. In Sharepoint case instead of POCOs you may use entities generated by SPMetal and implement repositories using Linq 2 Sharepoint while application layer should use only interfaces of these repositories in order to be independent from actual implementation. Repositories instances are retrieved using service locator. I will show examples in next part.

    My current understanding is that task of architect is to decide where to use DDD and custom model and where to use OTB feature. Quality of the architect will be determined by result of this balance DDD-OTB for the business.

    ReplyDelete
  4. This comment has been removed by the author.

    ReplyDelete
  5. Successful projects with DDD will be more successful without DDD.

    I've spend a lot of time refactoring DDD projects to non-DDD fashion and these projects become more maintainable and performance greatly improved.

    DDD tends to produce very large and complex code for simple functionality. But this conversation is not about DDD, it's about DDD in SharePoint.

    DDD in SharePoint is nonsense. You car create external system, even with DDD, and surface it in SharePoint. But it's no DDD in SharePoint.

    If you use SharePoint data (lists and libs) and create DDD model you loss a lot of functionality: versioning, attachments, approval, security, workflow, XSL web parts, search, etc. And you need to create a lot of code to provide support OOTB features.

    And simple SharePoint project with couple lists and workflows becomes very large and complex DDD project.


    Any abstraction have a cost, DDD abstractions itself very costly without real profit (money). In SharePoint cost of abstracting is too high, overwhelming any profit of abstractions.

    Can you provide any real profit (time saving, effort reduction, more performance, more flexibility) DDD in SharePoint?

    ReplyDelete
    Replies
    1. Agree with your point about the abstraction cost in SharePoint. However, occasionally, some sort of abstraction is essential, especially in complicated business scenarios. In these cases, the code tends to be completely non-readable and non-maintainable without abstractions. Myself I can recall at least two situations in our project at work, when common approach to SharePoint architecture failed completely.

      Personally I reckon DDD is a rightfull approach for SharePoint solutions architecture, however I would leverage DDD selectively, patchily. Only for key parts of the project, where it is absolutely necessary.

      In sum: architecture is matter of environment and applied forces. The most valuable quality of an architect is the ability to make correct decision and select the most suitable approach.

      Delete
    2. If DDD used as methodology for creating Ubiquitous Language, i.e. map business terms to SharePoint terms and create abstractions when it's necessary, then DDD is good. But when DDD starts with creating POCO classes and repositories it leads to poor solutions.

      Delete
  6. If you use custom databases in solution you loose basic SharePoint functionality - security, event receivers, versioning and approval.

    SharePoint reduces to asp.net web forms and workflow engine. And you need to put a lot of effort to create UI like SharePoint, search connectors, web services, provide backup\restore and manageability integration.

    Custom databases can be justified for platform extensions, like Project Server, or for analytic reporting (like Project Server too). But not for business solution. There is no place for DDD.

    ReplyDelete
    Replies
    1. > If you use custom databases in solution you loose basic SharePoint functionality - security, event receivers, versioning and approval.

      if I don't need these features, this is not a problem. If I need them - I won't use custom database

      > SharePoint reduces to asp.net web forms and workflow engine. And you need to put a lot of effort to create UI like SharePoint, search connectors, web services, provide backup\restore and manageability integration.

      yes creation of the UI will cost more in this case and you have to evaluate the efforts. But I will say obvious thing: if you will need to change something in the OTB functionality (which in my practice was in 100% of cases) it may cost a lot more comparing with custom solution which is much more flexible for any changes.

      > Custom databases can be justified for platform extensions, like Project Server, or for analytic reporting (like Project Server too). But not for business solution. There is no place for DDD.

      this sentence I didn't understood. Am I right that you said that custom database is not justified for business solution? Sharepoint is not database (another obvious thing) and should not be used instead of database. I already wrote sometime ago about example with project which we had integration via BizTalk with customers' ERP system. We got requests from BT were very often and each request causes many manipulations with data (requests may be processed whole night or even whole day). Sharepoint with 2,000 items limit or 5,000 items threshold would die very fast in this scenario.
      And this database was not only system extension and reporting data source. It was key element of the architecture.

      When I read such things I really think that you work with another types of projects rather that I, because from my point of view all of this is obvious.

      Delete
    2. If you don't use SharePoint features why you use SharePoint? Build separate solution, surface it in SharePoint with iframes, webparts or BCS.
      When you build solutions with SharePoint but your position is "I don't need this" its very painful when requirements are changed and suddenly you need some feature, but you don't use OOTB functionality.

      If limit of 5000 item per list per query scares you, then don't use SharePoint, build another thing. I've created SharePoint solutions which scales to terabytes of data and millions of items, but answers to user about 0,3 sec. It was pure SharePoint, without custom databases. With DDD this result will never be achieved.

      There are some scenario where SharePoint is not suitable, but in this situations custom SharePoint solutions don't work. Workload should be offload somewhere.

      For massive data processing - use separate databases and SSIS, it's not SharePoint solution. For enterprise integration - use BizTalk, but it separate solution too.

      Where is the place for DDD?
      What projects is successful with DDD and SharePoint?
      What profits give DDD to SharePoint projects with comparison to loses?

      Delete
    3. > When you build solutions with SharePoint but your position is "I don't need this" its very painful when requirements are changed and suddenly you need some feature, but you don't use OOTB functionality.

      in almost all of our projects situation was vice versa: in those areas where we used OTB features there was a need for little customization, which caused a lot of work. Result was the same: customers agreed to scope out the requirements, OTB was re-implemented. In some cases we also customized OTB solutions which is not recommended, but we knew the risks.

      > If limit of 5000 item per list per query scares you, then don't use SharePoint, build another thing
      that's what we are doing and happy with this.

      > With DDD this result will never be achieved.
      may be no, may be yes. How do you know it for sure if you didn't use DDD? When you make requests to the lists Sharepoint needs to map rows from content database to SPListItem. What is the difference if I will query custom database with lightweight mapper?

      > For massive data processing - use separate databases and SSIS, it's not SharePoint solution.
      if this data is part of domain model and should be used in Sharepoint, this is part of Sharepoint solution.

      > For enterprise integration - use BizTalk, but it separate solution too.
      this is what we do, but I don't understand how it is related with the subject.

      > Where is the place for DDD?
      What projects is successful with DDD and SharePoint?
      What profits give DDD to SharePoint projects with comparison to loses?
      I tried to answer these questions earlier.

      Delete
    4. >> in almost all of our projects situation was vice versa: in those areas where we used OTB features there was a need for little customization, which caused a lot of work.
      Very typical situation. But why you need this customization? It was real business need or just some person wanted it without business alignment?

      People often tries to create other system on top of SharePoint, not suitable for SharePoint. I'd rather create separate system and integrate it into SharePoint, or, more preferable, try to solve problem in terms of SharePoint. It's like DDD process of creating Ubiquitous Language in DDD. Process of creating Ubiquitous Language is mutual learning for stakeholders and developers. This learning is necessary for success.

      >> In some cases we also customized OTB solutions which is not recommended, but we knew the risks.
      Customizing OOTB is more recommended than creating new artifacts. Replacing OOTB with custom solution is not recommended. You should rely on OOTB feature and customize them to solve problems, not try to replace them.

      >> may be no, may be yes. How do you know it for sure if you didn't use DDD?
      I've used DDD, I still use DDD in analysis. But DDD pattern language is useless. Modern platforms and framework are much more powerful than DDD patterns can express.

      >> When you make requests to the lists Sharepoint needs to map rows from content database to SPListItem. What is the difference if I will query custom database with lightweight mapper?

      1) Versions
      2) Approval
      3) Event receivers, including third party
      4) Auditing
      5) Retention policies
      6) Workflows
      7) Attachments
      8) Search
      9) Web services
      10) OOTB customizable by end user interface
      11) Customizable by end user schema
      12) Security
      13) Alerts
      14) Integration with office clients
      Enough?
      Event if you don't need any of these features business requirements may change and you will need this feature. And you would write a lot of code to provide small subset of OOTB features.

      >>if this data is part of domain model and should be used in Sharepoint, this is part of Sharepoint solution
      SSIS script or external database can be a part of domain model? Any code runs in SharePoint context definitely doesn't know about SSIS. It's not part of domain and not a part of solution.

      Delete
    5. > ...
      Enough?
      Event if you don't need any of these features business requirements may change and you will need this feature. And you would write a lot of code to provide small subset of OOTB features.

      thank you for this education. This is correct direct answer on my question, but meaningless in context of the question. I told about data processing speed. You again tend to say me how cool OTB world is. And second probably I even should not ask this question, because as Vladimir correct said below when you told about terabytes of data of most probably told about files. I don't think that we need map files to the entities.

      > SSIS script or external database can be a part of domain model? Any code runs in SharePoint context definitely doesn't know about SSIS. It's not part of domain and not a part of solution.
      read my comment more carefully. I told about data, not about storage. Advantage which DDD gives you (or even more precisely one of its concept: repository) is independence from storage. My current understanding that repositories themselves are part of domain layer.

      Delete
    6. offtop: blogger marked you comment above as a spam. First time in the discussion. Don't know why it did this. Probably it also starts to understand something.

      Delete
    7. Why do you need independence of storage? What profit gives it to you? Most of feature relies on storage.

      Why do you need mapping to objects? Can you create queries in terms of objects?

      Delete
    8. > Why do you need independence of storage? What profit gives it to you? Most of feature relies on storage.
      testable code

      > Why do you need mapping to objects? Can you create queries in terms of objects?
      in order to write code in DDD style. Above I wrote why all of this is important (from my point of view)

      Delete
    9. SharePoint can be tested without abstractions. Abstractions can't be tested without SharePoint.

      For example how you will test repository for list if list have validation rules?

      Delete
    10. Станислав Выщепан,
      > SharePoint can be tested without abstractions. Abstractions can't be tested without SharePoint
      such sentenses just show that you do not familar good enough with the subjects where you try to discuss, sorry. And I do not have time/wish to explain it. People should have own head.

      > For example how you will test repository for list if list have validation rules?
      nohow, because initially Sharepoint is not testable system.

      Delete
    11. Try to discuss subject, not person.

      >>nohow, because initially Sharepoint is not testable system

      Oo
      You cant write small code to add list item and catch exception?
      It's called integration testing.


      If you want unit-testing it's almost pointless spending of resources. Most of SharePoint code calls SharePoint API, you need put a lot of effort to abstract SharePoint without any profit.

      If your code not calls SharePoint API or any other system then it can be tested without DDD and any abstractions.

      Delete
    12. > It's called integration testing.
      > If you want unit-testing it's almost pointless spending of resources

      exactly because of this I would like to stop this branch of discussion. We lost a lot of money trying to apply integration testing in Sharepoint, that's why I didn't want to discuss it. From my point of view this is "almost pointless spending of resources". It is too expensive in the current moment. We tried it in one of the project on Sharepoint 2007 several years ago, where we also tried to do other things suggested by IT pros. This project was saved only by developers while all IT pros were fired.

      I told about unit tests first of all. They are much cheaper. You can mock API with e.g. TypeMock for Sharepoint which works quite well. However in real life there is also no budget for this. But even in such conditions if you will write code which is simpler to test it will increase overall quality, you will get system effect at some point when whole system works as solid reliable mechanism.

      Delete
  7. Станислав Выщепан,
    > Successful projects with DDD will be more successful without DDD.
    again this is your opinion only, nothing more, sorry.

    > I've spend a lot of time refactoring DDD projects to non-DDD fashion and these projects become more maintainable and performance greatly improved.
    Performance is really important thing here and good that you mentioned it. Unfortunately it is really very easy to affect performance with improper use of DDD. Actually it is also easy with proper use - I admit that in order to be honest. Extra mapping layer will add costs. I faced with such situation in one of the project which became slower when data grew too much. We used simple SPSiteDataQuery under our repository layer and it was not enough.
    However as we had clean separation of concerns and responsibilities - it was easy to fix it for whole project by adding cache to repositories. Change was done only in repositories, application layer was not changed.

    > DDD tends to produce very large and complex code for simple functionality. But this conversation is not about DDD, it's about DDD in SharePoint.

    I'm talking not only about creating external system and surface it in Sharepoint (e.g. using application layouts pages). Such systems most probably will use DDD in my projects anyway. I'm talking also about DDD in Sharepoint. What code is more clear:

    1. Application layer code:
    var userAudiences = AudiencesHelper.GetAudiencesForCurrentUser(web.CurrentUser)

    var query = new SPQuery(...);

    var newsForUser = from i in list.GetItems(query)
    let targetAudiences = this.getAudiencesForNews(i)
    where targetAudiences != null && userAudiences.Intersect(targetAudiences).Count() != 0

    2. Application layer code:
    var news = newsRepository.GetNews();
    var newsForUser = audienceService.TrimByUserAudiences(web.CurrentUser, news);

    do you need to spend the same amount of energy in order to understand 1st example and 2nd?
    news collection in example 2 is not collection of SPListItems. It is collection of POCOs, so audienceService.TrimByUserAudiences() will look like this:

    var userAudiences = this.GetAudiences(user);
    news.Where(n => userAudiences.Intersect(n.Audiences).Count() != 0);

    > If you use SharePoint data (lists and libs) and create DDD model you loss a lot of functionality: versioning, attachments, approval, security, workflow, XSL web parts, search, etc. And you need to create a lot of code to provide support OOTB features.

    no you don't loose it. You just don't have to use DDD in the areas where it is not natural. As I said above this is the art of the architect to decide where to use DDD and were not.

    > And simple SharePoint project with couple lists and workflows becomes very large and complex DDD project.
    I'm not talking about simple projects. And yes it is hard to use DDD in many Sharepoint areas. Workflows is one of such areas. We have to live with the fact that a lot of functionality in Sharepoint has initially poor design, which forces us to develop functionality without any ability to write automated tests. And we should not use DDD in such areas - it will look non-natural and at the end will cause loosing of money.

    Unfortunately there is a lot of people who doesn't understand this and think that they are Sharepoint experts if they may configure OTB functionality without programming and say nice words to the customers. This is common mistake. Really good experts are those who have strong development background, which may create successful system regardless of the Sharepoint on any programming language or technology. These people are not actually developers, they are engineers. They are responsible for the their result. And they may write system even on brainfuck if needed.

    What books such people read in their free time? I may bet that not Sharepoint Workflows.

    ReplyDelete
    Replies
    1. >> 1. Application layer code
      >> ...

      >> 2. Application layer code
      >> ...

      Where this code runs? It's just code displays news for user in web part. It can e done with standard list with audience targeting and content by query web part. Completely without code. And it will be faster because audience filtering is done in query (you do this in application code) and query caching works for CQWP.

      This code already done for you, why don't just use it? It's tested, documented, globalized and supported by Microsoft. What profits of using DDD instead of it?

      >>You just don't have to use DDD in the areas where it is not natural.

      Where is DDD is natural? Nobody can show this area :)

      >>Unfortunately there is a lot of people who doesn't understand this and think that they are Sharepoint experts if they may configure OTB functionality without programming and say nice words to the customers.

      Unfortunately there is a lot of coders who think they know DDD, TDD, BDD, IoC, SOLID and other acronyms and trying to build solution with acronyms. And they don't understand SharePoint, don't know use cases, OOTB features and so on. But they thinks they DO and produces tons of ugly, plumbing, unsupportable code, unmaintainable and inflexible solutions.

      If you use SharePoint you MUST play by SharePoint rules. Experience with other systems\languages\paradigms won't help you if you don't know SharePoint.

      Delete
    2. > Where this code runs? It's just code displays news for user in web part. It can e done with standard list with audience targeting and content by query web part. Completely without code. And it will be faster because audience filtering is done in query (you do this in application code) and query caching works for CQWP. This code already done for you, why don't just use it? It's tested, documented, globalized and supported by Microsoft. What profits of using DDD instead of it?

      this code is example of one of the project which we have to maintain. It was run in custom web part. OTB audience targeting for list items was not used - there was a requirement to target items to audiences using managed metadata by end users. This managed metadata was used in another places for another purposes - and customers wanted to reuse it. So custom solution was implemented (I'm not 100% in details, because as I said project was not implemented by us).

      This example also shows why OTB was not used - you asked about it.
      And instead of trying to show that everyrhing can be implemented with little deviation by OTB functionality (believe me I know that), try to answer my question: what code is more clear? For me answer is obvious.

      > Where is DDD is natural? Nobody can show this area :)
      I would really want to say everywhere, but it is not true. I tried to answer this question before.

      > Unfortunately there is a lot of coders who think they know DDD, TDD, BDD, IoC, SOLID and other acronyms and trying to build solution with acronyms. And they don't understand SharePoint, don't know use cases, OOTB features and so on. But they thinks they DO and produces tons of ugly, plumbing, unsupportable code, unmaintainable and inflexible solutions. If you use SharePoint you MUST play by SharePoint rules. Experience with other systems\languages\paradigms won't help you if you don't know SharePoint.

      yes there are many people from other barrier - who doesn't know Sharepoint, but know popular idioms. But making good Sharepoint developer is much easy from good non-Sharepoint developer, rather then vise versa. E.g. we hire developers with strong ASP.Net skills and teach them Sharepoint. And it works well. So your sentence is not correct, at least in our case.

      Big salaries in Sharepoint area force some people to think that they are good "developers", while I can't even call such people developers. They are more experienced Sharepoint users.

      Another moment is that unfortunately in Sharepoint world it is easy to lost your developer skills. You have to spend energy to keep your skills on enough level. And it is caused by work approach which you mentioned. When you work with bunch of plugins why you need to care about code quality? You will mostly combine solutions made by other developers. I saw example of such degradation: developers after working Sharepoint created worse code in non-Sharepoint projects. Not all of course.

      Today I work with Sharepoint and ASP.Net MVC, tomorrow I will write program on python, after tomorrow - web interface for Haskell application. All of these have own rules, but also they have something common - I may use DDD in all of them. And I will play by rules until they won't force me to create a shit code.

      Delete
    3. You used DDD just because legacy? Perfect use case for DDD :)

      Can you provide real sample of DDD in SharePoint with complete code and without design errors (like using metadata for targeting instead of groups)?

      Delete
    4. > You used DDD just because legacy?
      sorry, didn't understand how you came to this conclusion? I showed the code where DDD is not used (which we got from another company) and showed how it may look with DDD.

      > Can you provide real sample of DDD in SharePoint with complete code and without design errors (like using metadata for targeting instead of groups)?
      from your point of view this is design error. From point of view of developers who implemented it, this approach solved another problems (e.g. problem of duplicating data in several places. May be it was crucial for customers, I don't know).

      Here is one example. We need to work with user profiles. In profiles we store company id which relates profile with particular company which is stored in external storage. For each user we have to determine his role, based on the company's attribute (e.g. based on company type, which as I said stored in external system). Get this requirement as is - I know that it is possible to store company type directly in user profile and avoid accessing of the external storage each time when we need to check the role. There are reasons why it can't be done.

      What is more convent for you:
      1. work with raw user profiles in application layer, make queries to external system in order to get company type, calculate user role

      var upm = new UserProfileManager(serviceContext);
      var userProfile = upm.GetUserProfile(loginName);

      string companyIdStr = userProfile["CompanyId"].Value.ToString();
      int companyId;
      if (!int.Parse(companyIdStr, out companyId))
      {
      // error
      }

      var company = MySuperDatabaseAccessStaticClassHelper.GetCompany(companyId);

      var userRole = Role.Unknown;
      if (company.CompanyType = "LikesOTB")
      {
      userRole = Role.Reader;
      }
      else if (company.CompanyType = "LikesDDD")
      {
      userRole = Role.Admin;
      }
      else ...

      if (userRole == Role.Reader)
      {
      // user doesn't have access
      }
      else if (userRole == Role.Admin)
      {
      // user has access
      }

      2. or this:
      var userProfile = userProfileService.GetCurrentUserProfile();
      bool hasAccess = securityService.DoesUserHasAccess(userProfile, url);

      userProfile here is mapped POCO, not OTB UserProfile instance. It has already initialized Role property, so inside security service we don't need to query external system. We need only do one responsibility: check does user have access or not.

      And please don't tell me about OTB security mechanisms. I know where it can be used, where not. Assume that OTB security can't be used.

      Delete
    5. >> From point of view of developers who implemented it, this approach solved another problems (e.g. problem of duplicating data in several places. May be it was crucial for customers, I don't know).

      Duplication is problem for relational database. SharePoint isn't relational database. It's closer to NoSQL databases with relies on denormalization in data modeling.

      It's not about point of view, it's about correct usage of tools.


      >>For each user we have to determine his role, based on the company's attribute (e.g. based on company type, which as I said stored in external system).
      There is only one correct way to do this - sync profile property with external system. If role changed often - create time job and sync every minute.

      >>Get this requirement as is - I know that it is possible to store company type directly in user profile and avoid accessing of the external storage each time when we need to check the role.

      If you know this , why don't do this?


      >>There are reasons why it can't be done.

      What reasons? If there is a real reasons (but I'm sure it's imaginary) then simpler to mitigate reasons and build solution without ugly, unrobust and slow code.

      >>Assume that OTB security can't be used.

      What reasons? If there is a real reasons (but I'm sure it's imaginary) then simpler to mitigate reasons and build solution without ugly, unrobust and slow code.

      Looks like I already wrote this.

      Your assumptions needs strong argumentation. Event if they are correct I see no reason to use DDD. There are more code structuring methodologies providing better result.


      PS. You code don't show DDD, this code may be written in any methodology.

      Delete
    6. seems like you don't want to understand point of view which differs from yours. I showed you several examples and everytime you try to tell me that it can be done by other way. This discussion become boring. I know people (who have a lot of certificates) who can't write web part, but who have a lot of cleaver words for you instead of direct answers and direct work (not about you), and this discussion tends to be similar.

      One more time: I know that it can be done by other ways (except fetching company type to user profiles via bcs, e.g. standard security mechanism + audiences). I do not want to hear it from you one more time. I want to hear answer on my question: what code looks simpler and more clear.

      > What reasons? If there is a real reasons (but I'm sure it's imaginary) then simpler to mitigate reasons and build solution without ugly, unrobust and slow code.

      there should not be delay in propagating of changes from external storage, because we are talking about security and about sensitive data (money). Hope you can live with that because I made this explanation last time.

      And yes "build solution without ugly, unrobust and slow code" is actually a good reason to use DDD.

      > Your assumptions needs strong argumentation. Event if they are correct I see no reason to use DDD. There are more code structuring methodologies providing better result.

      I don't have a goal to force you or someone else to use DDD. I use it in my projects and this experience is successful. Use methodology which gives better result for you (but try to hear opinion of others :) - sometime it is useful, sometime not). I wrote my thought. Someone will like them, some not - and this is completely Ok. For those who will find them reasonable it will be useful in real life.

      > PS. You code don't show DDD, this code may be written in any methodology.
      if developers will write that non-DDD code I will be happy.

      Delete
    7. Alexey, to be honest, your examples demonstrate merely a decomposition of some spaghetti code, and maybe applying some patterns (like Repository). They don't show DDD, really. Domain model assumes a bit more realistic, business examples.

      I believe your further posts will deliver more practical examples and will compare business-orientied model against other approaches rather than spaghetti code vs normal code :)

      Delete
    8. Andrey,
      I want to use examples from real projects where possible. For me DDD is more like style rather than static idiom. Do not expect very complicated models with hard business logic. Yes, code will be expressed in business entities and I will use DDD concepts (repositories and services). I will show how things can be done in DDD style. But I can't say where you have to use it and where not, because it depends each time on many factors. For discussions about why you should use DDD instead of OTB I posted this philosophical part. For another parts I would like to keep technical focus.

      As I understood the response from comments this theme is interesting. Let's continue and try to reach something (I'm still not sure what exactly). Probably we will get something useful from all of this.

      Delete
    9. Alex,
      >>I want to hear answer on my question: what code looks simpler and more clear

      Provide complete runnable code and I'll answer. You show two fragments of code on different level of detail.


      >>there should not be delay in propagating of changes from external storage, because we are talking about security and about sensitive data (money).

      What is "delay"? After user press the button in external system to commit transaction in database there is a delay. You can't avoid delays in distributed system, it's physical law.
      Then you should consider what is maximum delay for your scenarios.

      In you case I will create separate process, witch use SqlDependency class for external database (if SQL Server) and pushes changes to SharePoint user profiles.

      This is more robust solution. SharePoint will not crash if external system unavailable.

      >>I use it in my projects and this experience is successful

      I know only one type of projects successful with DDD - trivial projects. In simple project cost of abstractions is zero, profit is zero too, but no one cares because it's trivial.

      Delete
    10. Станислав Выщепан,
      > What is "delay"?
      try to turn on your own head, Ok? It is become annoying to chew everything. I know that it is hard when there is no "plugin" for this life situation and when nobody will solve the problem for you.

      > I know only one type of projects successful with DDD - trivial projects. In simple project cost of abstractions is zero, profit is zero too, but no one cares because it's trivial.

      hope that you will know them in future when will get more experience.
      And again, the fact that you don't know something, means only that you don't know something. Instead of saying that for everyone, try to fix it - read books not with only screenshots of wizards, but which will make your brain working.

      Delete
    11. Are you reading comments, or just firs sentence? I provided solution with minimal delay. And asked what real delay is acceptable. In real world there is always a delay.

      All notable books about DDD and OO design I've read about 5 years ago. There are not to much books. For many years I don't saw any big and successful project built totally with DDD.
      But saw a lot of projects witch can be done much simpler without DDD.

      You show same samples.

      Delete
    12. > Are you reading comments, or just firs sentence? I provided solution with minimal delay. And asked what real delay is acceptable. In real world there is always a delay.

      yes, and expect the same from you. Read comments below about customer rules more carefully (I'm not interesting in delays between clicking on the button and committing transactions. Such example is obvious and useless - that's why I was so emotional, sorry). But if we have requirement that data should be available in the system immediately after transaction have been committed, then I won't implement it with user profiles sync.

      > You show same samples.
      check my another comments. Although my code is expressed in business entities and can be called DDD from formal point of view (will try to show it in next parts), I wanted to combine under DDD umbrella many other concepts and want to show that it is possible to write good code in Sharepoint.
      If you don't see the value of DDD, probably some techniques will be still useful for you. E.g. it may help organize code even if you will work with List, instead of List.

      Delete
  8. > Any abstraction have a cost, DDD abstractions itself very costly without real profit (money). In SharePoint cost of abstracting is too high, overwhelming any profit of abstractions.
    if abstraction costs too high for you - you should not use abstraction. It really depends on the team and on level of developers. If you responsible for the team's result and don't see advantages of DDD and don't want to see them, you should work continue as you used to. It will be more efficient for you.

    Fortunately I was able to create conditions in the team where DDD gives advantages. We do not use DDD everywhere, do not try to battle with Sharepoint. Instead we try to apply DDD style wherever it looks natural, e.g. in custom functionality like application layouts pages, custom web parts, event and feature receivers, etc. For external systems which are hosted in Sharepoint (but can be regular ASP.Net application) - DDD is used in most cases.

    About profits:
    - clear code which leads to less bugs. Bugs are fixed within warranty contract for our own money, i.e. less money loose
    - separation of concerns makes changes simpler, gives more flexibility - customers are more happy. It is more likely that they will order another projects from you. E.g. we made a project which we got by public tender for one big customer. Another project they gave directly to us without tender. This is live money.
    - developers are more happy when they work with good code, instead of spaghetti shit. DDD tends to create good code. It leads to better productivity - which in turn in more money for the same time period.
    - many areas became testable - better overall quality. I have strong point that even if you don't have time to write unit tests, you anyway should write testable code. Better quality means less bugs which I already mentioned.

    ReplyDelete
    Replies
    1. All the profits you mentioned above could be achieved without DDD. Use patterns, use key development principles, like DRY, KISS, YAGNI and the SOLID pack, and you will achieve the same benefits.

      Key DDD idea is that the application model is built in terms of business requirements, so that the same terminology works equally well for the business users or sponsors and for the software developers.

      Delete
    2. > All the profits you mentioned above could be achieved without DDD. Use patterns, use key development principles, like DRY, KISS, YAGNI and the SOLID pack, and you will achieve the same benefits.

      yes, you are correct. For me DDD forces to use these concepts, forces to write good code. That's why I'm talking about DDD, and assume all the good things you mentioned (plus SRP). When use DDD all of these are applied in natural way.

      To be true I will glad if developers will write good code without DDD. But as practice shows if we use DDD it is simpler. So I decided to combine all of this under DDD umbrella.

      Delete
  9. >>clear code which leads to less bugs. Bugs are fixed within warranty contract for our own money, i.e. less money loose

    Clear code can be achieved without DDD. In SharePoint lot of things can be done without code.

    >>separation of concerns makes changes simpler, gives more flexibility - customers are more happy

    Not in SharePoint. If you build abstraction on SharePoint OOTB features can't work with it, and you need to write lot of code to achieve same level of flexibility. It's direct money loss.

    >>developers are more happy when they work with good code, instead of spaghetti shit

    DDD creates shit almost more often than non-DDD.

    ReplyDelete
    Replies
    1. > Clear code can be achieved without DDD. In SharePoint lot of things can be done without code.

      for me good code is the code which works without bugs and which is simple to change if requirement will be changed. As my experience shows for this code should be testable and understandable. You are right that it can be achieved without DDD, but with DDD is is simpler from my point of view.

      > Not in SharePoint. If you build abstraction on SharePoint OOTB features can't work with it, and you need to write lot of code to achieve same level of flexibility. It's direct money loss.

      again, I saw much more examples in other directions: when using of OTB features caused money loss. E.g. in one of the projects developers initially used BDC for showing data from custom database, only because they know that BDC can be used for that. As result in total weeks were spent for implementing this, more than 1 week was spent to solve all the issues in it. At the end customers added another requirement and we decided to get rid of it completely and used simple ADO.Net for querying the database. And it works very well still - we also added several other requirements in it without problems.

      However you position is also completely Ok and understandable. I always first consider OTB features wherever it is possible. But I also think about customers and another alternatives which I can suggest them. I know that if we will implement some functionality via OTB features and then infinitely customize the for "slight changes", we will always have work. And will always have clever words for explaining for customers why it takes so long in result. But will customers happy from this? Will you happy and will it be Ok for yourself?

      In order to solve such problems I estimate risks of using OTB features. These risks are decreased by tight communications with customers (I have to explain to them that if in future they will need this, this, and this, it will be hard. But using of OTB will give you this, this and this). Such conversations allows them to understand their requirements better and give me necessary context for making correct decisions. Custom solution may be changed at any time anyhow in most cases - and I also tell it to customers.

      > DDD creates shit almost more often than non-DDD.
      not in my experience.

      Delete
    2. >> I saw much more examples in other directions: when using of OTB features caused money loss. E.g. in one of the projects developers initially used BDC for showing data from custom database, only because they know that BDC can be used for that.

      Primary error was using external database. Or using database as is. I've used BCS for very complex database of document management system (desktop client). Most problems were solved by custom views in target database. Custom code were used for call stored procs in database, about 6 lines per proc.

      If custom database is prerequisite for DDD in SharePoint, then it architecture error and wrong usage of SharePoint.

      Delete
    3. > Primary error was using external database. Or using database as is. I've used BCS for very complex database of document management system (desktop client). Most problems were solved by custom views in target database. Custom code were used for call stored procs in database, about 6 lines per proc.

      first of all you don't know the context, how can you be sure that custom database was error? However I'm starting understand you: probably for you it is better to continue to work like you work currently: refactor DDD projects to OTB, solve problems by stored procedures (and think that this is Ok. Probably this is really Ok, hmm) and say that DDD in Sharepoint is nonsense.
      Because of some reason you don't want to see that it is possible to do successful projects and write good quality code in DDD style simultaneously.

      What will you do when need to write non-Sharepoint project? Also solve problems by moving logic to stored procedure? Or you made you choice and will work with Sharepoint whole life?
      People who work in my team may switch to another technology and use skills they got from Sharepoint development. What can Sharepoint "developer" answer on the interview if he works with your approach? Let's move business logic to stored procedures? Or that he can configure OTB CQWP and that's why in our Ruby team (ok, it is too extreem. In our ASP.Net MVC team) we should pay him 40K year?

      Point is that (unfortunately for many people), in order to be good specialist in Sharepoint you have to be good developer. Read a lot of books, arcticles, blogs, not only Sharepoint related. It is still hard.

      > If custom database is prerequisite for DDD in SharePoint, then it architecture error and wrong usage of SharePoint.
      in general agree, but as "custom database is prerequisite for DDD in SharePoint" is wrong (again I don't understand how you came to this), there is no sense to discuss this thought further.

      Delete
    4. >> first of all you don't know the context, how can you be sure that custom database was error?

      Because using of external database blocks a lot of OOTB features and extensibility. Instead of using external database it's preferable build separate system and integrate it into SharePoint.

      >>What will you do when need to write non-Sharepoint project?

      Depends on project. Without SharePoint I'll take most powerful tools to build application. But if I take SharePoint, I will use SharePoint features.

      >>Point is that (unfortunately for many people), in order to be good specialist in Sharepoint you have to be good developer.
      NO. Worst SharePoint solutions I saw was made by hardcore developers. Best solutions was done by IT pros who knows SharePoint feature and understands SharePoint.

      Ideal SharePoint solution - only configuration OOTB SharePoint features and external apps. There nothing to break in such solution.

      If you create custom code you should follow this philosophy. Custom components should be building blocks to create solutions (preferably by end user).

      Delete
    5. This comment has been removed by the author.

      Delete
    6. Станислав Выщепан, avishnyakov,
      as you are writing about similar things, I will answer to both of you:

      > NO. Worst SharePoint solutions I saw was made by hardcore developers. Best solutions was done by IT pros who knows SharePoint feature and understands SharePoint.

      this is from your experience. From my - IT pros (thanks for reminding this term) make shit spaghetti code which is impossible to maintain in long terms in large projects.
      E.g. we are not hiring IT pros, we are hiring developers with strong skills. I wrote about it.

      > It would say, the better point and the best SharePoint specialists are people who can make SharePoint solution without custom coding

      for me best Sharepoint specialist are people who make successful projects and make a lot of money for the company. In this sense as practice shows (I'm talking about my experience and about my projects) good developers can be such specialists.

      If you determined your way, it is your choice. Be "IT pro" - I don't see nothing bad in it. But it is not a choice for me. I would like to grow as architect and as developer and OTB world is not enough for this.

      Delete
    7. ITpros don't write much code. They don't know write large code and fail early. They write at maximum event receiver in 10 lines of code. This code may be thrown away and rewritten if requirements changed. There no need to support and maintain this code.

      Spaghetti code always written by hardcore developers.


      >>for me best Sharepoint specialist are people who make successful projects and make a lot of money for the company. In this sense as practice shows (I'm talking about my experience and about my projects) good developers can be such specialists.

      It's only your opinion, not confirmed by practice. Simple calculations shows that developer (who writes lot of code) many times less productive than ITpro (who configures OOTB and write very small amount of code).

      Good SharePoint specialist should be good ITpro first of all, and then may (not must) be a good developer.

      Delete
    8. > It's only your opinion, not confirmed by practice

      check my comment more carefully. It is not only my opinion - it is practice confirmed by years of Sharepoint development. And this is how we make business. When you will make business decisions, you may hire IT pros.

      Delete
  10. May be you have more examples with demonstration pros and cons of your point of view?

    ReplyDelete
  11. Eduard Kibort,
    I can't say for sure for all cases where to use OTB feature, where custom with DDD. In each case it depends from may factors. As I said in Sharepoint it is always balance and architect's art is to make this balance successful. In the next parts I'm going to show technical solutions which we used, and probably it will be more clear in what areas they can be used. But final decision whether to use it or not will be always on you as on architect.

    ReplyDelete
  12. Thank you. We'll see. DDD it is modern term, but realy it is one of the old OOP principals. For me if you have not so small application for wide market with long term perspectives you should use something like DDD. But if you have only simple webpart for single customer it can be useless.

    ReplyDelete
    Replies
    1. Eduard,
      I came to similar conclusion. And your understanding about what DDD is is close to my: it is just OOP with good encapsulation and with own dictionary of terms (entity, value objects, repositories, services, etc).

      Delete
    2. I have to disagree.

      The primary concept of DDD is that you should build your solution based on the Domain (the subject area, i.e. set of business objects and rules).

      In this case, developers and customers use the same terminology.

      Key part of DDD is using of the Domain Model, which was initially designed for complex domains, and defined by Martin Fowler as follows:

      At its worst business logic can be very complex. Rules and logic describe many different cases and slants of behavior, and it's this complexity that objects were designed to work with. A Domain Model creates a web of interconnected objects, where each object represents some meaningful individual, whether as large as a corporation or as small as a single line on an order form.

      DDD itself was defined by Eric Evans, who says:

      1. Focus on the core domain — “people get distracted by technology and we want to bring that attention back to the business domain”, said Evans. Even that whole business domain is too much to focus, according to him, and DDD requires us to focus on the core, the critical, most valuable part.
      2. Explore models in a creative collaboration with domain practitioners and software practitioners – “we have to collaborate, not just quiz [business experts] for requirements”.
      3. Speak a Ubiquitous Language in an explicitly Bounded Context

      These are the key concepts for DDD. Implementation details, like usage of entities and repositories, is the part of DDD too, of course, yet they merely suggest a way to implement the core principles. They aren't the heart of DDD in any case.

      Delete
    3. Btw, the quote from the same Eric Evans talk:

      The building blocks (entities, value objects…) aren’t really key to DDD, although most people initially thought that this is what DDD is about, said Evans.

      Delete
    4. Andrey,
      all of this is correct, I meant it by good encapsulation. Assume that people who will read it have read the books you quoted or at least know what they are talking about. Just when I feel that someone is on the same wave with me, I don't spent too much time describing the context.
      Also it will be more valuable if you will post your own thoughts instead of quotes. We all may read, but really interesting is what each of us thinks about it.

      Delete
    5. Alexey,

      I mean you don't have to use DDD building blocks at all: no entities, no services, no repositories, - nothing of it, and it will still be DDD.

      That's because using building blocks is just a recommended way to implement the main concept. There are, obviously, other ways to implement it.

      I think, in SharePoint, where cost of deep abstraction is very high, considering some other ways to implement DDD might be a good idea.

      My point, is that the Domain Model and DDD were designed primarily for the complex business domains. Thus, if you have complicated business scenarios, use it. If not, don't.

      For me, applying DDD is, first of all, coding in terms of business. Sticking to business objects, business rules and business scenarios as much as possible. This brings huge amount of benefits, mainly because customers and developers start to speak the same language, so they understand each other better. In complex business scenarios, this is essential: developers start to ask right questions, etc.

      I can't imagine how the term "good encapsulation" could mean this.

      In sum: although Eric Evans in his book mainly speaks about patterns in DDD, DDD is not about patterns. He himself emphasises this fact in most of his talks.

      P.S. I wasn't quoting any books. I understand that reading so great amount of comments could distract anyone, but it's really a bit offensive.

      Delete
  13. This comment has been removed by the author.

    ReplyDelete
    Replies
    1. > What would you recommend to use in this case as UI? - you have strongly-typed repositories/entities to play with and that's pure gold. How could I show all that data? - CQWP? - XsltListView? CoreSearchResult?

      thanks that you've mentioned that. Please wait until my next open source project and you will see :) It will require some time though.

      You are right that there are many OTB web parts which won't work with the custom model. And actually it can be a reason of why to not use DDD. One of the main idea of whole discussion is that DDD can be used and it is not a nonsense in Sharepoint projects.

      > What about integration w/ build-in rules, like field options/settings - required, default values, validation rules - and it's just a beginning.
      as far as I understand you are talking about list forms. I wrote above that there is no reason to change OTB list forms and make make them work via repositories. The goal is to keep successful balance OTB-DDD, not to use DDD everywhere.

      Delete
    2. This comment has been removed by the author.

      Delete
    3. from UI in most cases SPListItems are saved by list forms (although custom UI may be needed in some cases). But if we are talking e.g. about updating of list item in even receiver - then yes we can rely on OTB mechanism. In more complicated cases can implement custom validators or also rely on OTB. It's like database: in database you specify constraints, but for better user experience (e.g. in order to show all error messages at once and in user friendly form) when validation fails you check data in your domain layer also. Some tools (e.g. NHibernate Validator) help to automate it.

      In Sharepoint we don't have such tools, but it doesn't mean that we can't think about it and write code in the same style.
      Imagine that you would have SPHibernate, Fluent SPHibernate, SPHibernate Validator, SPHibernate Search, Linq 2 SPHibernate (wow, I wrote it) which would allow you to map SPListItems to entities in PI form and that OTB API would be integrated with it. Would you change your mind somehow?
      Above Stanislav wrote that Sharepoint close to NoSQL - but it is on implementation level because of denormalization of content db. For applied development Sharepoint lists are closer to relational database and we need mapping layer in most cases.

      Delete
    4. This comment has been removed by the author.

      Delete
    5. > Why would I use SPHibernate, Fluent SPHibernate, SPHibernate Validator, SPHibernate Search, Linq 2 SPHibernate and SP{DDD_OR_OTHER_COOL_WORD_MIGHT_BE_HERE_AS_WELL} instead of Nintex/K2?

      use those thing which works better in your case. I don't want to force you to use DDD. Grow as IT pro and be happy. Do you want the true: there is no happy at all. There will be a lot of problems always. No silver bullets, no happy life, and many other no.

      I was able to use DDD in good enough balance with OTB to do successful projects and want to grow more. And this is direction which I see for myself. I won't probably go to the user group where someone will show me another wizard, but I will probably go to the ALT.Net user group meeting (BTW on next week spb alt.net will make a virtual meeting and Artem Smirnov (author of Ivonna) will tell about FubuMVC framework. All are welcome - link will be announced soon).

      Delete
  14. This comment has been removed by the author.

    ReplyDelete
    Replies
    1. code expressed in content types/fields/workflows/CQWP/InfoPath/Search doesn't say anything for business in terms of business. It is not clean, logic is spreaded across many places, it is not testable, it is hard to maintain.
      You have to use it in Sharepoint, but it is not related with DDD.

      BTW - do you and Stanislav really think that OTB features in Sharepoint are so well implemented?

      Delete
    2. In terms of code structuring OOTB features are awful. But in terms of manageability, scalability, extensibility (sometimes) and business problem solving they are great.

      I always use SharePoint ECM features to prove this. It's build with very simple foundation: lists, libraries, content types, timer jobs and uses search. You can write very small amount of code to extend this features. You can augment your solutions with ECM features.
      It's great example of platform extension.
      For business solution you can create schema, workflows just in browser\SPD.

      Delete
  15. This comment has been removed by the author.

    ReplyDelete
  16. I think here were are talking about cases when important business requirements do no fit very good for Sharepoint. And you have to live with that - i.e. you are playing by customers rules.
    In such cases boundaries of platform will be expanded rather than business requirements will be changed (in my blog you may find many examples of such expanding). Probably it is different approach from yours, or you really didn't feel it _yet_. We have to be customer-centric in order to live in the market (in the fair market :)).

    ReplyDelete
  17. preventing further questions: I always try to explain alternatives and advantages/disadvantages of OTB solutions so customers may make decision themselves. Anyway - you have to play by customers rules.

    ReplyDelete
  18. Specialist always can argue his decision to non-specialist, even if decision is wrong ;)

    ReplyDelete
  19. yes, very true
    but result may be loosing of customer. I do not write DDD code, I make money, and customer happiness is _really_ important for me.

    ReplyDelete
  20. I think when you talk about OTB vs custom solutions you have conflict of interests. Creating custom solutions much more profitable for outsourcing \ consulting companys.

    ReplyDelete
    Replies
    1. Eduard,
      this is indeed good point. When you use OTB solution customers may replace you much simpler.
      They may also replace you if won't be satisfied with custom solutions. So increasing the basic development skills is important. Large projects can't be done by IT pros only.

      Delete
    2. >> Creating custom solutions much more profitable for outsourcing \ consulting companys.

      Outsourcing and consulting is very different. Outsourcers tends to do more to consume more money from customer. Consultants tends to do less work and give more profit to customers.

      For outsourcers custom solutions is good. No one else can support them.

      For consultants custom is bad because it needs strong support (more labor). Using existing features is much preferable for consultant because it increases profit without increasing of labor.

      But some outsourcers calls themselves consultants.

      Delete
    3. Stanislav,
      thank you for all your comments and for your time, but we have to finish it sometime. Your position is clear for us. This is the last your comment I've restored from spam. Good luck.

      Delete
  21. Summarizing all of this: there are people which feel that things which we discussed here can be useful. There are people which don't want to use DDD.
    And no matter how many comments we will leave here - it won't change these positions.

    For those who are interesting I will write next parts. Those who do not want to use it - may ignore it. But I want all philosophical discussions to stay here. In another parts I would like to concentrate on technical aspects. Decide use it or not by yourself.

    ReplyDelete