Tag Info

New answers tagged

1

If eventual consistency will not do then you'll need a way to store 100% consistent data on the transactional/write/domain side of things. That being said, it is sometimes possible to implement a business rule slightly differently but still get the same result. For instance, you could add a list of ChatAggregateComment value objects to your ChatAggregate ...


1

I'd implement a BanCommand class, which takes care of this. Domain models don't necessarily have to have state; sometimes they represent actions that take data and do something. That's pretty normal OO too; objects are behavior + state, but sometimes the objects don't really need any state to do something useful. That's why I always list behavior before ...


1

I would call one object's method from the other, to avoid code replication. I would find a way to do this like that : class BanService() { public function __construct(IUserRepo $userRepo) { $this->userRepo = $userRepo; } public function banUser($userId) { $this->userRepo->getUser($userId)->ban() } } or ...


0

The approach I've used a few times (I'm not sure if it's recommended or not) is as follows: Code business logic into dedicated business logic classes Have your entities use these business logic classes so that they aren't anemic Whether they're injected at construction, or simply directly instantiated is up to you. Any time I need a certain entity's ...


0

Your findBy methods don't couple you to the database structure, they couple you to business requirements. Personally, I don't mind repositories that have multiple findBy methods, as long as they are clean and neat. For example: User findById(string id); User findByEmail(string email); User findByUserName(string userName); To me seems like a clean ...


2

Depends what you mean by synching. Usually, a repository is used by controllers. So Controller is the one to draw from it and to place data back. Also, controller triggers methods like .save(), that in turn would be implemented by repository and will push data to persistence layer(PouchDB) in your case.


0

Maybe you are missing a layer. Without knowing the details of your application (requisites, architecture, etc) I would do something like Client (whoever it be) -> Application Service -> Domain Model The application service layer is allowed to interact with the repository and the domain model containing the business logic. So you can have something like: ...


1

You are leaving out the possibility of restricting the input in the database. If there can indeed only be one review of a particular movie by a particular user, that should be a database constraint. If you do that, then your concern is how to handle a failed attempt to insert a second review -- how does that get reported to the user.


3

In a DDD (Domain Driven Design) application using a conventional layered architecture, business logic goes into the domain layer. Now, please note this layer does not only contain the domain entities (Movie, Review), but also domain services (like a ReviewService class) and repositories. So, ReviewService is a business class as well. Your concern about ...


2

Having watched the section of the video you refer to, I don't see where Scott says a Bounded Context should correspond to a module. He just happens to chose a module to represent the Bounded Context in his example. There is absolutely no reason that a Bounded Context must correspond to a module. If you feel your Bounded Context does not map well to a ...


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 ...


4

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 ...



Top 50 recent answers are included