Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
We follow 3-tier architecture, where we have presentation layer, business logic layer (Managers) and Data Access Layer.
There are few processes that involves multiple entities which are controlled by different BLL classes (we refer to BLL classes as managers).
Can we have one Manager class interacting horizontally with another Manager class.
Wanted to know the opinion of the community, as just relying on Manager-DAL flow is creating a lot of code duplication.
I don't see anything particularly wrong with that also this happens more often than you might expect. In a layered client application for example, within the data layer you'll usually find a class that speaks to a framework / platform specific cache (usually it writes to the HD). Since the framework and data layers are on the same low abstraction level, it is fine for them communicate without having an architectural break.
The main thing that should be avoided is a dependency direction from the more abstract layers (entity / domain / business layer) to the less abstract layers (data or presentation layers).
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
We know in java, encapsulation is a process of wrapping up of code data together into a single unit or hiding the data. Can anybody let me know from whom we are hiding the data?
You are "hiding" data from users of your object that should be able to use it without needing to know about its internals.
The main reason for this is to allow you to later change these internals without breaking the code that calls into your object.
This is a technique to improve software maintainability.
Common misconception: It should definitely not be seen as a security measure (in the sense that it protects sensitive data from malicious actors that should not be allowed to gain access to it -- encapsulation does no such thing).
Data hiding is a software development technique specifically used in object-oriented programming (OOP) to hide internal object details (data members). Data hiding ensures exclusive data access to class members and protects object integrity by preventing unintended or intended changes.
Data hiding also reduces system complexity for increased robustness by limiting interdependencies between software components.
That's why Data hiding is also known as data encapsulation or information hiding.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I have a project in DDD and I would like to know in which layer I have to code a Service to consume an external service. In this case the external service is about information (especifically payment slips) to show in the Front-End.
The question is a bit vage, but my guess is that you have a bounded context and you even have an UI for this bounded context. Now you would like to show some data from another (external)BC in the UI of your BC.
Before creating an application service for that, ask yourself: what should the user do with this information? Does it help to solve some business problem of your BC? Does the user take different actions inside your BC depending on the payment slip data that he or she sees? If so, then you probably need to model those busines rules explicitly inside the domain model of your BC, create some sort of relationship to the other BC and agree on a contract to get the data to satisfy your invariants.
If you just need a shortcut/convienience for the user in the UI then try to push this feature to the UI level, maybe a simple link to the other context is enough...
Reaching out to external BCs should not be done careless, since every external dependency makes your BC less independent and valuable on its own. First try to clarify the communication to the other context using one of the strategic design patterns like anti-corruption-layer, customer-supplier, conformist etc. After this analysis it should be easier to determine in which layer an how you would put the logic for this external call.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
The facade pattern is to provide a simplified interface for complex code.
Therefore, it is correct to use it as a wrapper for a system? That would be like a translation map for facilitating the understanding hiding the complexity?
Is it correct then call all Facade as API?
Well the programming interface into any application is the Application Programming Interface, so yes it would be an API, in the same way that your OS has an API keeping you from fiddling with too much memory or abstracting the hard drive - or a game engine has an API acting as a facade for graphics and audio code.
So yes, the implementation of a Facade is an API, but so is any other code which you use as an interface into a more complicated system. (I guess you could ask the question as "are all APIs a facade that just provides a layer of abstraction?" - and you could probably make the argument that it's true).
It's a bit of an odd question to consider however, because depending on who you talk to, these terms may change - we only really use them to represent the idea of abstraction, as we see fit.
Remember that design patterns are not hard fast rules. A Facade is an API that reduces the complexity of using some system. That system may be a single library, multiple libraries, various network clients, etc.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
If you had to create a list of steps that a non-technical business layperson would understand for implementing workflows in something like Mule ESB -- what would it look like? The scenario would be to describe how the ESB is used to perform integration between two disparate systems and the steps you would need to perform to get the job done.
An Enterprise Service Bus is a technical middleware for system integration. It is doubtful whether mixing the business aspects into the picture makes sense. For business people to look at a picture and 'get it', the technical aspects would either be abstracted away and or require a tacit understanding of the technology. Better to keep them separate.
On the business logic level you should use BPML for workflow modelling:
http://en.wikipedia.org/wiki/Business_Process_Modeling_Notation
The technical aspects of a service bus are captured through Enterprise Architecture Integration patterns:
http://www.eaipatterns.com/toc.html
The EAI view is already abstract, but expecting business people to understand this is like handing them UML diagrams and assuming they're literate by nature (alas, they are not).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Thinking about service orientation, our team are involved on new application designs. We consist in a group of 4 developers
and a manager (that knows something about programming and distributed systems). Each one, having own opinion on service design.
It consists in a distributed system: a user interface (web app) accessing the services in a dedicated server (inside the firewall), to obtain the business logic operations.
So we got 2 main approachs that I list above :
Modular services
Having many modules, each one consisting of a service (WCF).
Example: namespaces SystemX.DebtService, SystemX.CreditService, SystemX.SimulatorService
Unique service
All the business logic is centralized in a unique service.
Example: SystemX.OperationService. The web app calls the same service for all operations.
In your opinion, whats the best? Or having another approach is better for this scenario?
A web service is an interface. The invoker doesn't care how a service works, it just needs to know what arguments to supply and what outcomes to expect. So a multitude of simple, discrete servcies is probably better.
Behind their interfaces they can all join up in one great big bundle of business logic. Who cares?
In practice, teach of hese services will share some elements of SystemX functionality and will have some elements which it alone uses. Some may combine elements of SystemX and SystemY. If SystemX and SystemY are legacy apps it may not be possible to change them, so we have to work with them as they are. In other scenarios it is possible to expose impose modularity on them.