Tag Info

New answers tagged

0

It seems to me that you're just missing a class definition. Declare a class CustomerOrders with GetOrdersTotal method. It's a pure business object. There no such table in the db. It wraps an Order DAO and applies business rules on on it (active order, filter by customer id). So, OrderRepository is your DAL and CustomerOrders is your BL


1

What is business logic code and what is data access code, and what's the difference? There is a short answer to that: a) Code, that is used to open a connection to a DB, to retrieve data, do OR-mapping etc. is called data access code static public int AddProductCategory(string newName, string connString) { Int32 newProdID = 0; string sql = ...


4

The database layer is intended to isolate the rest of the application from the details of the database -- how to make a connection, the syntax used to talk to the db engine, etc. The .Net Entity Framework version of your code would be: var id = customer.id; var customerOrdersTotal = db.Orders. Where(o => o.CustomerId == id ...


0

Sounds like you are using domain entities for both domain operations (commands, which modify application state) and queries (which don't modify application state, but return data for the user). The problems you describe are a direct result of trying to get that single domain entity to do both jobs, which don't mix very well. My recommendation is to read on ...


3

The idea in Udi's post, as I gather, is that no kind of item appears out of thin air. There is (almost) always something, or more specifically, some domain operation, which caused the item to be created. Just like Udi's example of a user actually being born out of a visitor registering to the site. At that point and at that bounded context Visitor is the ...


1

In CQRS, queries are not allowed to have any side effects, and thus they cannot change any data. Commands on the other hand must not return any data, but change the state of the application. With these definitions and your problem domain the question becomes this: What does the search functionality do? If it's purely for finding an order, then it is not ...


2

Let's go back to good old SOLID principals. Currently, your Gateway is: Providing integration with Web Interface AND Checking for an item in users inventory. You broke Single Responsibility principal :) Is it terrible? No, not really, but, trust me, it's much easier to correct it now, while you don't have a large application instead of correcting things ...


3

In general, a gateway class should translate from the interface you have to the interface you want. If the interface you want is a simple presence check, by all means write it that way. I would just caution you as the requirements change and the application grows, to not be afraid to reevaluate that decision. If your gateway class starts looking too ...


4

The most architecturally sound approach I know of is to put that single source of truth behind a microservice. It is perfectly okay for multiple parts of the system to update that data, as long as they do it through something like a microservice that can ensure it's always done correctly and predictably. So for instance, Customer data is probably already in ...


1

Ok. Problem 1: getting DTO's from entities: Since your entities can expose thier data publicly you can access their properties and instanciate a DTO object or simply serialise the entity directly Problem 2 : Entities from DTO's: A constructor method which takes a list of the properties to be set can be called using the properties of the DTO Problem 3 : ...


1

There's nothing wrong with the backing state DTO approach, in fact it's recommended by some DDD people. However, populating a domain object from heterogeneous sources is not the main reason for it. It's more about solving the entity encapsulation vs persistability paradox by having an object that is easily accessible and mappable by ORMs. ...


1

The approach that I have used in the past that can be applied in MVC & WebAPI projects follows: End Point (Controllers, ApiController) return ViewModels (DTOs) Business Layer / Application Layer / Domain Service - return application data Data Access Layer - Repository Pattern - returns DB Model Entities Each layer is responsible for its own data. ...


3

I think you want to go for a design of normalization within one Bounded Context. If one aggregate is a pure subset of the other (e.g. the product for cart is a subset of the product for product) I'd probably use a single table. Otherwise, I'd probably use a second table that refers to the first table rather than duplicating columns between two tables. For ...



Top 50 recent answers are included