business-logic

In trying to understand Domain Driven Design I keep returning to a question that I can't seem to definitively answer. How do you determine what logic belongs to a Domain entity, and what logic belongs to a Domain Service? Example: We have an Order class for an online store. This class is an entity and an aggregate root (it contains OrderItems). Public Class Order:IOrder { Private List<IOrderItem> OrderItems Public Order(List<IOrderItem>) { OrderItems = List<IOrderItem> } Public Decimal CalculateTotalItemWeight() //This logic seems to belong in the entity. { Decimal TotalWeight = 0 foreach

I'm having a design issue in my project, related to where put some business logic. I have three entities, Event, TicketOrder and Ticket. One Event has a lot of TicketOrders and one TicketOrder has a lot of Tickets. In my template, I have to show how many tickets an Event has. I've thinking of the best approach to achieve this and didn't get a good solution. I've tried this: 1) Create a private member 'ticketsCount' in Event entity, with setTicketsCount and getTicketsCount method. Create a 'loadTicketsCount' method with a LifeCycleCallback 'PostLoad', to access the TicketRepository method

I am working on a project using entity framework. Is it okay to use partial classes of the EF generated classes as the business layer. I am begining to think that this is how EF is intended to be used. I have attempted to use a DTO pattern and soon realized that i am just creating a bunch of mapping classes that is duplicating my effort and also a cause for more maintenance work and an additional layer. I want to use self-tracking-entities and pass the EF entities to all the layers. Please share your thoughts and ideas. Thanks aqwert I had a look at using partial classes and found that

I am gonna build a service using 3-tier architecture and I am really worried about how to handle operations in a transacted way. I know I have 2 options: IDbTransaction and TransactionScope ... but I am not really decided for which one to go, although I did a lot of research. I would go for TransactionScope but I don't want to involve DTC... plus I need support for SQLServer2005 and Oracle. (I am aware that I need to have only one connection opened at a time) I would like to see good examples/patterns of their usage for both cases... Good links would do just fine. Something like how a BL class

Closed . This question is opinion-based. It is not currently accepting answers. Learn more . Want to improve this question? Update the question so it can be answered with facts and citations by editing this post . I'm building a MVC web application (using the Spring MVC framework), and I'm a little stumped on the best way to design a particular area. The application has to interact with a series of web services which are not really all that greatly designed, and don't offer much abstraction in and of themselves - basically there is a web service method for each create/update/retrieve/delete

I am working on a decision engine / rule evaluation engine. For example: Input: Customer and all the offences done by the customer Output: Consequences of the offences A sample case would be: Input: Customer(Jhonny Chimpo, 999-00-1111), Offences ( Broke window, slapped boss, kicked team lead in his groin) Output: Gets pink slip So the piece of code I want to write evaluates different offences based on rules for each offence and combined offence. The current code is just a maze of if and else statements. I am sure such business problems are common. What design/enterprise pattern is usually used

I'm an ASP.NET MVC developer just starting with my first big project on rails however Im confused as where to put your business logic? on ASP.NET I create a library which contains services(Domain driven design) which handle business logic, I have heard that rails uses a concept of fat model skinny controller but I have some projects in ASP.NET which adding all the logic to the controller would create a big mess, is there any other way? Go with the concept of FatModels and SkinnyControllers. Your models should know how they behave and what they should do. When your models get too fat, extract