If someone tries to implement the CQRS pattern without repository in DDD, in which layer should it be done? Infrastructure or Application Layer?
If you mean the implementation of the handlers of the queries and commands, it's done in the application layer.
But you need a repository to abstract the technological implementation outside of use cases/interactors (application layer).
The Infrastructure layer is responsible for encapsulating technology. You can find there the implementations of database repositories for storing/retrieving business entities, message brokers to emit messages/events, I/O services to access external resources, framework related code and any other code that represents a replaceable detail for the architecture.
Related
I'm getting started using Lagom in Java and have a need to write a custom (de)serializer. I've read through the documents and understand the roles of the NegotiatedSerializer, MessageSerializer, SerializerFactory etc. What I don't understand is in which package it is canonical to define the class. I've looked at the Chirper sample and see that there are often concrete model definitions alongside the *Service interfaces in the various *API modules, but there are no examples of custom Serializers. Thanks for the help!
Serializers for messages (request bodies, response bodies, and messages published to a topic) should be part of the service's api module. Serializers need to be used both by clients of the service and by the service implementation itself. This makes them part of the service interface or API.
Serializers for persistence (commands and replies, persistence events, entity state) should be defined in each service's impl module. They are details of the internal implementation and should not be exposed to clients.
Beyond those broad guidelines, the way you organize your package structure is really up to you. Some projects use a single package for the API and a different one for the implementation. Others might divide each into sub-packages, though as services should generally stay pretty small and focused, this might be overkill. You should arrange the packages in a way that makes sense for your project and organization.
I am developing a WPF application, that connects to several WCF services (that work with LINQ-TO-EF).
The WPF is designed in MVVM fashion.
For each WCF Service I have the following:
Service Layer DLL - this includes the service interface, service implementation. the service implementation just creates BL objects and calls methods on them
Service BL Layer DLL - this includes a manager factory (factory creates UserManager, TaskManager etc). Each manager has an interface + implementation (for unit-testing purposes and DI). For example - TaskManager has 'GetTasks', 'CheckTaskIsValid' etc. In addition, the BL Layer has a 'Trasnlator' class to translate from Data-Entity to DTO. The BL manager methods return DTOs to the service layer.
In addition to the above, all the service BLs reference the Data Access Layer DLL that includes:
EDMX file with tables from MS SQL Server
Auto-Generated DbContext + POCO entities
Query providers (used by BL manager classes). Each query provider has an interface+implementation for unit-testing and DI purposes.
DbContext factory - interface+implementation, for unit-testing and DI purposes.
The services are in CQS design (Command-Query-Seperation, not to mix with CQRS), meaning that there is one service responsible for querying only and one service responsible for sending commands.
I am using DI (using AutoFac) through my WCF Host Project that hosts all the services (I implemented IInstanceProvider, so that I can inject dependencies to the services).
I did not implement my own repositories or unit-of-work, because DbContext already is UoW and Repositories.
Is this design flawed ?
I have read a lot of posts about DDD, and I know that my design is not DDD.
My question is - is my design good enough ? Do I need to refactor all my code towards DDD ? (using aggregates and root aggregates etc).
I have tried to provide as much detail as possible about the design, so I hope I don't get answers like 'Your question is too general' or 'Need some examples'... Any helpful information would be very much appreciated !
Yes, you have not DDD design, but not-DDD doesn't means bad design. I think when your system is testable and flexible for further development, scales good for your needs - than you have good system design for your needs.
All other sounds good except:
I did not implement my own repositories or unit-of-work, because
DbContext already is UoW and Repositories.
Not implementing your UoW and Repositories means you are tightly coupled to Entity Framework and it could be problems with testability. But you can cover it with integration test again test database. Unit tests for database logic sometimes tests itself.
Do you need DDD? Maybe when system will be more complex than evolutional you will come to DDD and to CQRS. But when it's enough for you, easy to maintain and for further development, testable, scaling, when system is not fragile, than I think, it's better to focus on business needs
In an n-tier architecture, the best place to put an object-relational mapping (OR/M) code is in the data access layer. For example, database queries and updates can be delegated to a tool like NHibernate.
Yet, I'd like to keep all references to NHibernate within the data access layer and abstract dependencies away from the layers below or above it. That way, I can swap or plug in another OR/M tool (e.g. Entity Framework) or some approach (e.g. plain vanilla stored procedure calls, mock objects) without causing compile-time errors or a major overhaul of the entire application. Testability is an added bonus.
Could someone please suggest a wrapper (i.e. an interface or base class) or approach that would keep OR/M loosely coupled and contained in 1 layer? Or point me to resources that would help?
Thanks.
It sounds like you are looking for the repository pattern. If you need more decoupling, you can inject the data dependencies with an Inversion of Control container.
Service Facade Pattern is one name. Simple contracts between business logic and data layer.
Service classes or beans (call it what you want) define and implement the contract, and orchestrate the lower data layer, often handling the transactional logic across data objects.
In Spring, you define an Interface, and then implement it. One implementation might be an OR/M, another might be raw JDBC or ADO.NET. In some frameworks, Aspect Oriented Programming allows you to inject declarative transactional logic without writing any code. It saves a lot of headache.
One caveat: When dealing with some OR/Ms like Hibernate, there is the use of proxy classes. This does pollute things, because there are a few instances where the proxy classes cause problems. In my opinion, that is an implemtation detail that should not escape the service layer. But with Hibernate, it does. Not sure about the .NET implementation.
I have a repository (CustomerRepository) that retrieves data from the data layer. Most of the business logic is in the entity class (Customer) that the repository either accepts or returns.
However, where do you put the global entity business logic (that applies to all customers)?
For instance, I may not want to return all customers to certain users. I don't want to put that logic in the repository.
I agree with Robert Munteanu.
Basically you roll up your business logic that isn't inherent in your model into a middle tier. The middle tier is the business tier / business objects / business logic layer / etc, but is just referred to as a service tier. It doesn't have to be a webservice, its a broad use of the term service in that it aggregates functionality of a specific application area.
You would basically have a CustomerService class that contains the repository reference. Your presentation layer would reference the service layer class.
There is an additional distinction that can be made as a guess from your name you are using .net, and probably using LINQ to SQL as your repository as outlined in NerdDinner.
The Repository typically returns IQueryable to the service layer, allowing the service layer chain together multiple queries to build different result sets. The Service then evaluates the expression using ToList or another similar method and returns that to the presentation layer.
Put it in another repository (BusinessRuleRepository) and have CustomerRepository use it.
OR
If the business logic is only limiting the results a user can see you might want to use a Facade pattern with a factory. In this case you would have an ICustomerRepository that handles your CustomerRepository and LimitedCustomerRepository (which might encapsulate CustomerRepository), and a CustomerRepositoryFactory that returns the appropriate ICustomerRepository for the user.
Wrap it behind a service.
I think separating these types of functions into a service layer is the way to go.
I recently built a system to do complex forecasting with many entities using historical data. Putting all the data access bits in the repository for each entity. The intricate forecasting logic I kept in a service layer and passed the repository objects in as needed.
Added bonus was that I had an easy way to expose all the forecasting logic to external systems by simply creating a web api layer.
What is the proper way to handle polymorphic business objects in a WCF/SOAP world?
It seems to me that SOA and OOP are at odds with each other - to expose a clean WSDL you need concrete objects, typically not even utilizing inheritance. On the other hand, presumably in the underlying system, you'll want to follow proper OO design.
What do people typically do here? Build a set of WCF contract objects, forgoing OOP principles, then convert to and from another set of objects in the actual logic layers?
What do people typically do here? Build a set of WCF contract objects, forgoing OOP principles, then convert to and from another set of objects in the actual logic layers?
Yes.
The way WCF serializes things ends up putting a lot of limitations on what you can and can't do with the contract objects. What you can't do ends up being "most anything useful".
I've found it makes things much clearer if you think of the WCF-contract objects as just a data transfer mechanism. Basically like strongly/statically typed XML.
Instead of converting your business object to an XML string (and back again), you convert your business object to a WCF-contract object (and back again), but it's otherwise similar
After reading the Thomas Erl library, I came to the following conclusion:
Think of the WCF Contracts/SOAP Message as simply a message that the Services use to communicate (don't tightly tie that to Objects in your code).
You can then use OOP to design a code-base that gracefully handles those messages using common OOP techniques.
You use an abstraction (interface type) annotated with WCF attributes in order to define your Service contract.
This is both depending on abstraction, which is according to OOP, as well as defining a service endpoint, which is SOA.
In general, if you find that you are getting business objects with dependencies, you should consider pulling such dependencies up to the service business layer as opposed to inject dependencies into the business objects.
The service business layer will then act as a mediator acting on both the WCF service proxy as well as the business objects. As opposed to having the business objects acting on the WCF service proxy.
All great comments on this topic! I'll add my vote to the notion of an adapter for mediation between your service orientation and object orientation. I also like Thomas Erl's approach where in his service model he introduces the notion of "application services" and "business services." These are the way to go for your integration points with your specific application/business environment (i.e. your object oriented and component oriented framework/API). This way should result in much better composability and thus capability, for you enterprise framework gurus out there.