Microsoft Spain - Domain Oriented N-Layered .NET 4.0 Sample App

New Post: Development of Microsoft Spain

cesardl — Tue, 21 May 2013 23:50:06 GMT

Could be! J

Send me an email (to cesardl at microsoft.com) so we plan offline, ok?

There are quite a few things we could do..

Cheers,

Cesar.

New Post: Development of Microsoft Spain

brunobertechini — Tue, 21 May 2013 22:33:43 GMT

Cesar,

Would you like any help on getting this Project going forward? I really would like to help so submit patches or anything else I can do to keep this Project going...

Bruno

New Post: Is it wise to abstract the entities?

brunobertechini — Tue, 21 May 2013 21:08:19 GMT

Nice to hear that :)

Cesar, if you could have a look at these thread, I will appreciate:

Infrastructure.Logging - EventSource

WCF Error Handler

Regards

Bruno

New Post: WCF & Exception Handling Improvements for V2.0

brunobertechini — Tue, 21 May 2013 21:07:15 GMT

I figured out by myself:

I have changed the code from :

ApplicationErrorHandler.ProvideFault

//create service error
ApplicationServiceError defaultError = new ApplicationServiceError()
{
   ErrorMessage = Messages.message_DefaultErrorMessage,
};

To:

//create service error
ApplicationServiceError defaultError = new ApplicationServiceError()
{
   ErrorMessage = error.Message // Modified to include the exception raised
};

I have changed this so my custom exception type (DomainException) get forwarded to the client. (Of course I am forwarding only known exception - my custom type)

At the client:

try
{
     // Call proxy.Action
}
catch (FaultException<ServiceError> ex)
{
   properties.Status = SPEventReceiverStatus.CancelWithError;
   properties.ErrorMessage = ex.Detail.ErrorMessage;
}

Thank you very much!

Bruno

New Post: Is it wise to abstract the entities?

cesardl — Tue, 21 May 2013 19:42:16 GMT

Thanks a lot for the feedback Bruno! J

I agree with your comments, of course.

Cesar de la Torre.

Microsoft Corp

New Post: Buenas prácticas

brunobertechini — Tue, 21 May 2013 19:10:25 GMT

Well,

I have to tell you the "inconvenient" is a word that leads me to "maintenance problems in the feature" in your case.

I mean, every time you need something different on your View, you have to change your domain behavior. Is that correct?

Every time you need diferente business logic that may change properties of na existing entity, you would have to change every view that uses it.

Again: DTOs are not "for convenience" only. If you use them correctly and also create a Service Layer Approach you would benefit of separation of concerns.

I know its hard to build things "right". But thats the price to pay for a good system.

You can do it step-by-step. A very good approach is: REfactor your code as you have new features. Like: Every time you "touch" one class, refactor it to use DTOs. And when you realize, everything would be using it. So you can start phase 2 and create na intermediate layer like na AppService (from DDD).

I think you are not doing DDD right on App Layer. The App layer should be a mediation between Presentation (user) and the domain layer. You have the domain layer right on presentation.

If you want to have the benefits of DDD, my advice is to refactor your code slowly...but create a goal and work for it :)

Any help you need let me know

Bruno

New Post: Is it wise to abstract the entities?

brunobertechini — Tue, 21 May 2013 19:02:45 GMT

Hi Alex,

Sorry for the delay, but I am on a busy month (as Always) :)

My suggestion for you is: Embrace DDD and NLayerAppV2 as much as you can.
It will help you a lot if your system is intended to have a very long lifecycle and will stay there for a while.

I am working on a system I can call it medium/big and the advantages are so huge I cant think how I could work without these Technologies and approaches.

I am still on a learning courve, but I think I have solid practical implementations of NLayerAppv2-like Project by now. I am not using CQRS yet (still to come in next months). I am using Sharepoint 2013 to behave as my "Message Bus" and also for Presentation and sometimes App layer.

The thread you mentioned above was initiated by me a while ago. I was discussing with Cesar regarding basic methodology to get the hands on Bounded Contexts, Modules and others DDD terms in practical.

I will be very gratefull if I can help you guys in anything you need to design or code your app. I can do my best to provide you my suggestions and experiences :)

Again: I would definitely go for DDD and services-aware approach for a big solution as you are intended to build.
Regardless if current products do it or not. They may have tons of reasons to build the way they do: time, legacy versions, compatibility, lack of DDD maturity at the time of development, and many others.

So my final word is : Go for DDD, period. Talk to your business, define your entities/modules/bounded contexto and use NLayerAppV2 as a tech guide. Im sure you'll be happy in the future.

Regards

Bruno

P.S.: Feel free to share anything else or popup any other doubts/questions.

New Post: Infrastructure.Logging - Event Source

brunobertechini — Tue, 21 May 2013 18:50:23 GMT

Hi Cesar,

By now, I have almost 95% of my Project implemented according to NLayerAppV2.

Have to say: Its wonderfull. It really helps. Thanks a lot. And congratulations for the good work so far.

I have one question regarding ILogger:

Would you think its a good idea to create a method at ILogger interface to set the source string for a event log ? That would help a lot.

Like SetSource(string sourceName) so we can use it for eventlogs (Windows) , filenames (Text) and so on.

Would like to know your thoughts about it.

Regards

Bruno

New Post: Is it wise to abstract the entities?

Cyberdude3 — Fri, 17 May 2013 09:14:38 GMT

Hi Bruno,

No. We are not going to build on top of any CRM. I wanted to give an example to clarify the type of our application. So, it would be a completely separated application with almost the same functionalities as most CRM applications.

Alex

New Post: Is it wise to abstract the entities?

brunobertechini — Fri, 17 May 2013 00:59:46 GMT

Hi Alex,

Are you going to build your App on top of Microsoft CRM or would it be a completely separated app?

Bruno

New Post: Is it wise to abstract the entities?

Cyberdude3 — Thu, 16 May 2013 19:08:25 GMT

Hi,
We want to build an enterprise application which does have many CRM functionalities. And we are stuck with a very important architectural decision. When we look at Microsoft CRM 2011 we see that all entities are in the database. It looks like that there is a huge abstraction layer similar to CMS has been build and used to build the application. As the result without using SDK, a programmer should write code like dynamic["Account"] to get the customer instead of just write Account acc = new Account().
Well, we don't want to rebuild the MS CRM, we just want to know is it wise to build an application which
1- has multiple different UI and services (mobile app, windows service, asp.net mvc web)
2- has accounts, products, orders, bills, discount and that kind of entities
3- and the products has many different attributes and dependencies on each other

with an CMS?
Because to me, a CMS makes entities abstract by defining each as a as content. So you could see all entities in the some database table of the CMS. Just like most CRM's have.

Or we could use an architecture like this great example of Domain Oriented N-Layered sample application. When we do that, we will use entlib 6.0 and Unity 3.0 as well and build WebApi's for all type of client app's.

I know that without the knowlegde over the domain nobody can make such decision or advice. But see it as a CRM application.
By the way this post https://microsoftnlayerapp.codeplex.com/discussions/431320 was also help for us. But didn't make the decision any easier :-)

Any help would be greatly appreciated.

Regards,
Alex

New Post: Buenas prácticas

fjaumot — Thu, 16 May 2013 18:41:41 GMT

Hello!
I understand you now! :)
Yes, this is a inconvenient but this is not compensable work involved in creating DTO project where there are many entities (97 in this and 192 on the other we have with DDD). Is there any way of linking OFF, automatically create them, etc. ..?

Thanks for all!! :) it's a great conversation with u :)

New Post: Buenas prácticas

brunobertechini — Thu, 16 May 2013 17:01:29 GMT

fjaumot wrote:

Hello Bruno, !
Beacuse I need the DTO? I dosen't understand this.
I have,

UX (mvc)
Project.BackOffice (ViewModel, Controller, Js, View...)

Application
Project.Application (use repositories and entities)

Domain
Project.Domani.Entities (Created by t4 and used in Application and UX)

Data
Project.Data (EDMX, Context (t4) with UnitOfWork and Repositories)

I dosen't understand because I need to use DTO... Because I dosen't use POCO Entities??

Thank you!!

Because, in my opinion, you should never use Domain Entities outside the domain and Application Layers.

Simple example: If you have "full rich entities" right at the controller, why do you have Application layer?

For example, lets say the Invoice entity has a "Process" method. And youre suppose to handle it using na AppService right? like you did InvoiceManagementService.

Regardless the existence of this InvoiceManagementService, right on controller you can do something like:

invoice.Process() --> And this would break something in your domain since youre not using your Application logic from InvoiceManagementService.

Business logic should never leave domain boundaries.

I try to use a mix of DDD and Union Architecture for better maintenance:
http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

Bruno

New Post: Buenas prácticas

fjaumot — Thu, 16 May 2013 16:47:53 GMT

Hello Bruno, !
Beacuse I need the DTO? I dosen't understand this.
I have,

UX (mvc)
Project.BackOffice (ViewModel, Controller, Js, View...)
Application
Project.Application (use repositories and entities)
Domain
Project.Domani.Entities (Created by t4 and used in Application and UX)
Data
Project.Data (EDMX, Context (t4) with UnitOfWork and Repositories)

I dosen't understand because I need to use DTO... Because I dosen't use POCO Entities??

Thank you!!

New Post: Buenas prácticas

brunobertechini — Thu, 16 May 2013 16:43:33 GMT

fjaumot wrote:

Yes, I call two ManagementServices (Application) from Controller.

And what is your question? If it is correct to call 02 application services from controller? If so, YES it is.

Try to build your Presentation layer using Composition.

You can have even different bounded contexts in your view/presentation layer.

Check this out http://skillsmatter.com/podcast/design-architecture/talk-from-udi-dahan

Bruno

New Post: Buenas prácticas

fjaumot — Thu, 16 May 2013 16:40:51 GMT

Yes, I call two ManagementServices (Application) from Controller.

New Post: Buenas prácticas

brunobertechini — Thu, 16 May 2013 16:34:55 GMT

Please refactor your code and create Application services mediating between presentation and domain layer.

They will accept/return only DTOs and inside those methods they will do "in memory" operations over your POCO classes and perform repositor operations if needed.

Can you post your Application Services so we can see how are you doing this?

Bruno

New Post: Buenas prácticas

brunobertechini — Thu, 16 May 2013 16:33:02 GMT

fjaumot wrote:

No I agree. Why reason I need to use WCF if I have a distributed application? My POCO classes are serializable, all I do is save the original serialization in the MVC (compressed JSON) and then not have to recover the original entity and add directly to context. Is not that right approach?

What do you mean by "distributed application"?

This is not the recommended approach. Don't use your POCO (Domain) classes over the wire. They must be "Statefull" and perform business operations.

That's why you have DTO (Data Transfer Objects) to "transfer" objects over the wire. These DTOs would have only data needing by your controller.

I think you are missing the whole concept of Application layer from Evans book...

Bruno

New Post: Buenas prácticas

brunobertechini — Thu, 16 May 2013 16:30:16 GMT

fjaumot wrote:

An other question,

In one controller, I have use a differents ManagementService?
Like this,
   public BankAccountController(IBankingManagementService bankingService, ITransferManagementService transferService)
        {
            _BankingService = bankingService;
            _TransferService = transferService;
          
        }
Thanks for you help!

Are these AppServices being called from within the controller? Didnt understand your question.

Bruno

New Post: Buenas prácticas

brunobertechini — Thu, 16 May 2013 16:27:13 GMT

This InvoiceManagementService.cs is running in which layer? I mean, Is it a ApplicationService or Domain service? It looks like a AppService, since it is using repositories and transaction... Try to name it InvoiceManagementAppService to be more clear though.

Without knowing your domain better (Invoice/Contract) I cant tell you what's the right approach in my opinion.

As per my understanding, Invoice and Contract are both Aggregate Roots of diferente Aggregates. Am I right ?

If so, why are you deleting and old contract just because a new invoice is coming up ?

Have you read about Udi Dahan "never delete" approach ? I strongly recommend it. In summary: Never delete! -> Do some "logical" delete like disabling the entity
http://www.udidahan.com/2009/09/01/dont-delete-just-dont/

Also, check this link http://stackoverflow.com/questions/14696568/avoid-unit-of-work-pattern-in-domain-driven-design
"In a properly designed system one command changes one aggregate at a time, every aggregate has boundaries which defined by invariants in aggregate root. So when you do any changes on aggregate, invariants are checked and changes are applied (or not) in one transaction. It's transaction consistency. Do you need to use Unit of Work here? Don't think so.
But quite often we are in situation when more then one aggregate need to be changed at one time. Transactions become larger, they touch more then one part of a system and we talk about eventual consistency. UoW is a good helper in this case.
"

Please make sure your UnitOfWork pattern is working as expected. You should have One UnitOfWork for both repositories. Commit would save them both in one transaction.

Bruno